AppCrawler

Simple example of C# program accessing Oracle

Steve — Wed, 16 May 2012 02:23:09 +0000

Nothing big, just a placeholder for an example of what is in the subject line.

//C:\Users\showard>C:\Windows\Microsoft.NET\Framework\v2.0.50727\csc.exe  /r:"C:\oracle\product\11.2.0\client_1\ODP.NET\bin\2.x\Oracle.DataAccess.dll" checkConn.cs
 
using System;
using Oracle.DataAccess.Client; 
 
public class checkConn {
  public static void Main(String []args){
    OracleConnection conn = new OracleConnection("User Id=biztalk;Password=********;Data Source=fn9dev");
    OracleDataReader rdr;
    try {
      conn.Open();
      OracleCommand cmd = new OracleCommand("select sysdate from dual", conn);
      rdr = cmd.ExecuteReader();
      while (rdr.Read())
        Console.WriteLine("Server time is " + rdr[0]);
      conn.Dispose();
    }
    catch(Exception e) {
      Console.WriteLine(e);
    }
  }
}

Which tables have changes in a GoldenGate trail file?

Steve — Mon, 07 May 2012 13:02:26 +0000

I use the following to identify which tables have changes recorded in a trail file, as well as how many changes each table has…

CMHLDECOMDB01:oracle:cmhecomd1:/u01/app/oracle/acfsmounts/ggate/oracle2/dirdat>strings -a r1000009 | grep ATGDB | sort | uniq -c
      6 ATGDB_CORE.DAS_ID_GENERATOR
  21873 ATGDB_CORE.DCSPP_ORD_ABANDON
  10937 ATGDB_CORE.DCS_USER_ABANDONED
CMHLDECOMDB01:oracle:cmhecomd1:/u01/app/oracle/acfsmounts/ggate/oracle2/dirdat>

ACFS install on CentOS

Steve — Wed, 25 Apr 2012 19:29:30 +0000

I run CentOS on a test cluster, and every time I patch it with a PSU or whatever, my ACFS installation is trashed as CentOS is not officially supported.

To fix this, change the following section in $GRID_HOME/lib/osds_acfslib.pm…

  if ((defined($release)) &&                     # Redhat or OEL if defined
      (($release =~ /^redhat-release/) ||        # straight RH
       ($release =~ /^enterprise-release/) ||    # Oracle Enterprise Linux
       ($release =~ /^oraclelinux-release/)))    # Oracle Linux
  {

…to…

  if ((defined($release)) &&                     # Redhat or OEL if defined
      (($release =~ /^redhat-release/) ||        # straight RH
       ($release =~ /^enterprise-release/) ||    # Oracle Enterprise Linux
       ($release =~ /^centos-release/) ||        # CentOS hack
       ($release =~ /^oraclelinux-release/)))    # Oracle Linux
  {

…then re-run the ACFS install as root and you should be good to go.

[root@expressdb1 ~]# /u01/app/11.2.0/grid/bin/acfsroot install
ACFS-9300: ADVM/ACFS distribution files found.
ACFS-9312: Existing ADVM/ACFS installation detected.
ACFS-9314: Removing previous ADVM/ACFS installation.
ACFS-9315: Previous ADVM/ACFS components successfully removed.
ACFS-9307: Installing requested ADVM/ACFS software.
ACFS-9308: Loading installed ADVM/ACFS drivers.
ACFS-9321: Creating udev for ADVM/ACFS.
ACFS-9323: Creating module dependencies - this may take some time.
ACFS-9154: Loading 'oracleoks.ko' driver.
ACFS-9154: Loading 'oracleadvm.ko' driver.
ACFS-9154: Loading 'oracleacfs.ko' driver.
ACFS-9327: Verifying ADVM/ACFS devices.
ACFS-9156: Detecting control device '/dev/asm/.asm_ctl_spec'.
ACFS-9156: Detecting control device '/dev/ofsctl'.
ACFS-9309: ADVM/ACFS installation correctness verified.
[root@expressdb1 ~]# exit
logout
expressdb1:oracle:+ASM1:/u01/app/11.2.0/grid/lib# crs_start ora.registry.acfs
Attempting to start `ora.registry.acfs` on member `expressdb1`
Start of `ora.registry.acfs` on member `expressdb1` succeeded.
expressdb1:oracle:+ASM1:/u01/app/11.2.0/grid/lib#

Using DBMS_LOGMNR with GoldenGate logdump

Steve — Mon, 23 Apr 2012 15:25:07 +0000

I honestly don’t know if we will ever use this, but I thought it was useful enough to document.

One of the things I struggled with early in our GoldenGate testing was what an RBA was. The term was flipped around in the documentation, sometimes with an EXT on the front (EXTRBA), sometimes not. Regardless, it was confusing to me because Oracle also uses the term RBA for “Redo Byte Address”.

The bottom line is that an RBA in GoldenGate is simply the current read position of the source data, whatever that may be.

For a “regular” extract, it would be the “normal” Oracle RBA, or exact position in the redo log from which the Goldengate process is extracting Oracle database transactions for replication. For a datapump extract, it is the byte position (or read checkpoint) in the proprietary GoldenGate trail file that is being written by the “regular” extract process. For a replicat, it would be the byte position (or read checkpoint) in the proprietary GoldenGate trail file that is being written by the datapump extract process on the source.

If for whatever reason, you need to tie the position in a “regular” trail file to what is in the Oracle database, you can do what is below.

Get the transaction of interest in the trail file using the GoldenGate logdump utility…

Logdump 539 >n
___________________________________________________________________
Hdr-Ind    :     E  (x45)     Partition  :     .  (x04)
UndoFlag   :     .  (x00)     BeforeAfter:     A  (x41)
RecLength  :   142  (x008e)   IO Time    : 2012/04/23 10:10:46.000.000
IOType     :     5  (x05)     OrigNode   :   255  (xff)
TransInd   :     .  (x03)     FormatType :     R  (x52)
SyskeyLen  :     0  (x00)     Incomplete :     .  (x00)
AuditRBA   :        113       AuditPos   : 25834512
Continued  :     N  (x00)     RecCount   :     1  (x01)
 
2012/04/23 10:10:46.000.000 Insert               Len   142 RBA 2733
Name: ATL.ORDER_DETAILS
After  Image:                                             Partition 4   G  s
 0000 0028 0000 0024 3333 3335 3965 6166 2d65 3465 | ...(...$33359eaf-e4e
 302d 3462 6636 2d39 3431 342d 3438 6438 3337 3666 | 0-4bf6-9414-48d8376f
 6338 3337 0001 0028 0000 0024 3635 3730 6161 6437 | c837...(...$6570aad7
 2d33 6337 382d 3430 6361 2d61 3639 322d 3335 6431 | -3c78-40ca-a692-35d1
 3430 3465 3062 6333 0002 0028 0000 0024 6333 6437 | 404e0bc3...(...$c3d7
 6561 6332 2d33 3138 362d 3436 6135 2d38 3433 652d | eac2-3186-46a5-843e-
 6333 6336 6135 3534 6439 3661 0003 0006 0000 0002 | c3c6a554d96a........
 
GGS tokens:
TokenID x52 'R' ORAROWID         Info x00  Length   20
 4141 4145 5030 4141 4641 4141 424d 5741 4165 0001 | AAAEP0AAFAAABMWAAe..
TokenID x4c 'L' LOGCSN           Info x00  Length    7
 3636 3539 3638 34                                 | 6659684
TokenID x36 '6' TRANID           Info x00  Length    9
 3331 2e31 372e 3539 37                            | 31.17.597
 
Logdump 540 >

We then take the sequence (AuditRBA) and Oracle RBA (AuditPos) for this change and find it in the archived redo log using DBMS_LOGMNR. Please note that a redo block in Oracle is 512 bytes (in Linux, at least), so we multiply the RBABLK column for a given change by 512 and add the “trailing” RBABYTE, or number of bytes into that block, at which the change is recorded.

SQL> SELECT name FROM v$archived_log WHERE sequence# = 113;
 
NAME
--------------------------------------------------------------------------------
+DATA/express/archivelog/2012_04_23/thread_1_seq_113.475.781351919
 
SQL> exec dbms_logmnr.add_logfile(logfilename => '+DATA/express/archivelog/2012_04_23/thread_1_seq_113.475.781351919');
 
PL/SQL procedure successfully completed.
 
SQL> exec dbms_logmnr.dict_from_online_catalog + dbms_logmnr.no_rowid_in_stmt);
 
PL/SQL procedure successfully completed.
 
SQL> SELECT scn FROM v$logmnr_contents WHERE rbablk * 512 + rbabyte =  25834512;
 
       SCN
----------
   6659681
   6659681
 
SQL>

It is interesting to note that the SCN recorded in the trail file is for the commit on the transaction. The transaction itself was recorded with an SCN three whole numbers lower.

SQL> SELECT sql_redo FROM v$logmnr_contents WHERE scn = 6659681;
 
SQL_REDO
--------------------------------------------------------------------------------
SET transaction READ WRITE;
INSERT INTO "ATL"."ORDER_DETAILS"("ID","ORDER_ID","PRODUCT_ID","QUANTITY") value
s ('33359eaf-e4e0-4bf6-9414-48d8376fc837','6570aad7-3c78-40ca-a692-35d1404e0bc3'
,'c3d7eac2-3186-46a5-843e-c3c6a554d96a','63');
 
SQL> SELECT sql_redo FROM v$logmnr_contents WHERE scn = 6659684;
 
SQL_REDO
--------------------------------------------------------------------------------
commit;
 
SQL>

How often does GoldenGate checkpoint?

Steve — Wed, 11 Apr 2012 22:29:53 +0000

While running a 10046 trace against a replicat session, I saw UPDATE statements against the checkpoint table. While this isn’t unexpected, as I had configured the replicat to use a checkpoint table, I was curious to see how often it did. in other words, is it every 3 seconds, or every 100 rows, etc.

I wasn’t surprised, as it is never that simple, to find it somewhat random. To verify, I ran a test with several thousand INSERTs per minute against two tables, ORDERS and ORDER_DETAILS. I then extracted the CURSOR # in the 10046 trace for each statement, and ran the following awk against the trace file.

expressdb1:oracle:express1:/u01/app/oracle/diag/rdbms/express/express1/trace# cat a.awk
{
  if ($0 ~ "EXEC #47821729564056" || $0 ~ "EXEC #47821729706488") {
    j++
    found=1
  }
  else if($0 ~ "XCTEND rlbk=0, rd_only=0" && found=1) {
    split($0,t,",")
    split(t[3],s,"=")
    PROCESSED++
    if (last > 0 && (PROCESSED <= 10 || PROCESSED >= 100)) {
      printf("Inserted %i rows in %.1f seconds before checkpointing\n",j,(s[2]-last) / 1000000)
    }
    j=0
    last=s[2]
  }
}
expressdb1:oracle:express1:/u01/app/oracle/diag/rdbms/express/express1/trace# awk -f a.awk express1_ora_23158.trc
Inserted 701 rows in 1.3 seconds before checkpointing
Inserted 236 rows in 2.9 seconds before checkpointing
Inserted 399 rows in 10.1 seconds before checkpointing
Inserted 22 rows in 1.7 seconds before checkpointing
Inserted 75 rows in 3.3 seconds before checkpointing
Inserted 458 rows in 4.1 seconds before checkpointing
Inserted 107 rows in 1.2 seconds before checkpointing
Inserted 339 rows in 7.2 seconds before checkpointing
Inserted 164 rows in 5.0 seconds before checkpointing
Inserted 263 rows in 5.4 seconds before checkpointing
Inserted 89 rows in 3.1 seconds before checkpointing
Inserted 121 rows in 5.5 seconds before checkpointing
Inserted 160 rows in 2.0 seconds before checkpointing
Inserted 363 rows in 4.3 seconds before checkpointing
Inserted 107 rows in 13.6 seconds before checkpointing
Inserted 303 rows in 1.8 seconds before checkpointing
Inserted 120 rows in 2.4 seconds before checkpointing
Inserted 118 rows in 1.3 seconds before checkpointing
Inserted 204 rows in 2.3 seconds before checkpointing
Inserted 333 rows in 6.1 seconds before checkpointing
Inserted 64 rows in 4.3 seconds before checkpointing
Inserted 198 rows in 9.9 seconds before checkpointing
Inserted 6 rows in 7.0 seconds before checkpointing
expressdb1:oracle:express1:/u01/app/oracle/diag/rdbms/express/express1/trace#

When I did the math, I found the time between checkpoints was as low as about a second, and as high as 13 seconds. The median and average was about two seconds. The INSERT execution counts between checkpoints, as you can see above, are all over the map.

No real information, but I thought it was interesting.

Programmatically creating GoldenGate confliction detection filters

Steve — Wed, 11 Apr 2012 16:01:41 +0000

EDIT: 2012/05/01 I changed the PL/SQL code below, as I found that creating a filter per column eventually exhausts the hardcoded limit on the number of filters you can have for a table (20). I changed it to do a count of records where each and every column’s before value matches each and every columns current value in the target. I am having issues with line length when I do this, so this may be updated again.

Out of the box, Golden Gate will not detect any conflicts in which the target data is different than what the source is prior to submission. If a row doesn’t exist that is sbumitted for update from the source, that will throw an ORA-01403. If you try to insert a row into the target for which the primary key value already exists in the target, and ORA-00001 will be thrown by the database, as you would expect.

However, assume you have a row in the source such as…

PRODUCT_ID 10
INVENTORY_QUANTITY 100

…that is then updated to…

PRODUCT_ID 10
INVENTORY_QUANTITY 90

…and the target has an update made directly to it like…

PRODUCT_ID 10
INVENTORY_QUANTITY 40

When the update to 90 is sent to the replicat on the target, GoldenGate will not throw any exceptions, and will update the INVENTORY_QUANTITY to 90.

Monday morning, the guys in the warehouse are trying to ship product that doesn’t exist in the inventory system. It might go something like, “hey, we are missing 50 units.” Ouch…

What is below will programmatically create filters for checking prior to update to ensure there wasn’t an update on the target about which we didn’t know. We didn’t want to implement all kinds of conflict handlers as we are in the midst of an ATG implementation, and don’t understand the data well enough to make those decisions in advance. This will simply trap an issue if it exists and abend. That is acceptable to us in the short run for two reasons:

We don’t want to accept the risk of making an incorrect business data decision and doing more harm than good

We are practicing conflict avoidance by creating sticky session profiles at the network layer that tie an account to a particular data center. As such, we don’t expect a *lot* of conflicts.

What is below simply creates select of all columns other than the primary key where the value = what it was on the source before the update. If a matching “pre-version” row is not found on the target, an exception is thrown.

The beautiful thing about this is that GoldenGate does not execute the “filter” SQL for every update. It must be smart enough to check the incoming values and what it is in the target before updating. I know this because I ran a 10046 trace against the replicat process, and the select for the “filter” was only parsed, never executed during a test with thousands of updates. However, as soon as I forced in a conflicting update that was considered for processing by the replicat, the select filter was executed and the replicat process abended (because the check didn’t pass).

As such, you don’t have to worry about the overhead of the filter. I think that is what is meant by an extraction map, it just maintains it in memory.

SET serveroutput ON size unlimited
spool conflict.OUT
SET lines 1000 trims ON
SET echo off
SET feedback off
DECLARE
  /*
  Simple anonymous block that will read the dictionary for a given schema and output rules that will detect conflicts
    if after an update all column values other than the primary key have changed since the update was issued on the
    source.
  */
  skip NUMBER := 0;
  p_source VARCHAR2(30) := 'ATGDB_EXPRESS_CORE';
  p_target VARCHAR2(30) := 'ATGDB_EXPRESS_CORE_REP';
 
  TYPE t_columns IS TABLE OF VARCHAR2(30);
  colns t_columns := t_columns();
 
  TYPE t_keys IS TABLE OF VARCHAR2(30);
  keys t_keys := t_keys();
 
  PROCEDURE get_columns(p_table IN VARCHAR2) IS
    i NUMBER := 0;
    l_skip NUMBER := 0;
  BEGIN
    FOR col IN (SELECT column_name
                  FROM dba_cons_columns dcc
                  WHERE table_name = p_table
                    AND owner = p_source
                    AND EXISTS (SELECT 1
                                  FROM dba_constraints dc
                                  WHERE owner = p_source
                                    AND dc.table_name = dcc.table_name
                                    AND dc.constraint_name = dcc.constraint_name
                                    AND dc.owner = dcc.owner
                                    AND constraint_type = 'P')
                  ORDER BY position
                ) LOOP
      keys.extend(1);
      i := i + 1;
      keys(i) := col.column_name;
    END LOOP;
    i := 0;
    FOR col IN (SELECT column_name FROM dba_tab_columns WHERE table_name = p_table AND owner = p_source) LOOP
      FOR j IN 1..keys.COUNT LOOP
        IF keys(j) = col.column_name THEN
          l_skip := 1;
          EXIT;
        END IF;
      END LOOP;
      IF l_skip = 0 THEN
        colns.extend(1);
        i := i + 1;
        colns(i) := col.column_name;
      END IF;
      l_skip := 0;
    END LOOP;
  END;
BEGIN
  FOR tab IN (SELECT table_name FROM dba_tables WHERE owner = p_source) LOOP
    DBMS_OUTPUT.put_line('map ' || p_source || '.' || tab.table_name || ', target ' || p_target || '.' || tab.table_name || ', &');
    DBMS_OUTPUT.put_line('sqlexec (id ' || tab.table_name || '_check, on update, beforefilter, & ');
    get_columns(tab.table_name);
    DBMS_OUTPUT.put('query "select count(*) cnt from ' || p_target || '.' || tab.table_name || ' where ');
    FOR j IN 1..colns.COUNT LOOP
      IF j = 1 THEN
        DBMS_OUTPUT.put(colns(j) || ' = :p' || j);
      ELSE
        DBMS_OUTPUT.put(' and ' || colns(j) || ' = :p' || j);
      END IF;
    END LOOP;
    FOR j IN 1..colns.COUNT LOOP
      IF j = 1 THEN
        DBMS_OUTPUT.put('", & ' || CHR(10) || 'params (p' || j || ' = ' || colns(j));
      ELSE
        DBMS_OUTPUT.put(',p' || j || ' = ' || colns(j));
      END IF;
    END LOOP;
    DBMS_OUTPUT.put_line(')), &');
    DBMS_OUTPUT.put_line('filter (on update, ' || tab.table_name || '_check.cnt >  0, raiseerror 9999);');
    DBMS_OUTPUT.put_line(CHR(10));
    keys.DELETE;
    colns.DELETE;
  END LOOP;
END;
/

Print thread dump for a single thread

Steve — Mon, 09 Apr 2012 16:27:31 +0000

We had an issue where a single thread was using all the CPU. We wanted to check it at the command line while troubleshooting. We used what is below…

[atg@CMHLDECOMAP01 ~]$ jstack 3000 | awk '{if ($1 == "\"Thread-9\"") {i = 1;print $0} else if (i == 1 && $0 != "") {print $0} else if (i == 1 && $0 == "") {exit}}'
"Thread-9" daemon prio=10 tid=0x000000000c849800 nid=0xbd7 runnable [0x0000000041595000]
   java.lang.Thread.State: RUNNABLE
        at org.apache.log4j.Category.getEffectiveLevel(Category.java:439)
        at org.apache.log4j.Category.isDebugEnabled(Category.java:733)
        at com.arjuna.common.internal.util.logging.jakarta.Log4JLogger.isDebugEnabled(Log4JLogger.java:317)
        at com.arjuna.common.internal.util.logging.jakarta.JakartaRelevelingLogger.isDebugEnabled(JakartaRelevelingLogger.java:73)
        at com.arjuna.common.internal.util.logging.LogNoi18nImpl.isDebugEnabled(LogNoi18nImpl.java:108)
        at com.arjuna.ats.arjuna.coordinator.TransactionReaper.check(TransactionReaper.java:169)
        at com.arjuna.ats.internal.arjuna.coordinator.ReaperThread.run(ReaperThread.java:122)
[atg@CMHLDECOMAP01 ~]$

This will print the call stack of that given thread, and that given thread only.

GoldenGate simple conflict resolution example

Steve — Sat, 07 Apr 2012 13:27:53 +0000

I found it incredibly difficult to find a simple working example of an inventory type system where a user at SITE A updates the inventory for ‘Bowl’, while at SITE B another user updates the inventory at the exact same time. Normally, without conflict detection and resolution, each update would be replicated to the other database, at which point you would have out of sync data. In other words, update SITE A to 20, and SITE B to 30. After each change is replicated, you have inventory of 30 at SITE A, and 20 at SITE B.

Assume we start with what is below at each site…

CREATE TABLE inventory(id number PRIMARY KEY, quantity number);
begin
  FOR i IN 1..10 loop
    INSERT INTO inventory VALUES(i, i * 10);
    commit;
  end loop;
end;
/

I found it easy to detect this conflict with what is below in the replicat parameter file at each site, changing the schema names. In other words, flip the CMH and ATL in the SITE B replicat file from what it is at SITE A (we have two different schemas in the same database for testing)

map CMH.INVENTORY, target ATL.INVENTORY, &
sqlexec (id INVENTORY_check, on update, beforefilter, &
query "select QUANTITY from ATL.INVENTORY where ID = :p1", params (p1 = ID)), &
filter (on update, before.QUANTITY = INVENTORY_check.QUANTITY, raiseerror 9999);

If a row with the expected “before” update quantity was not found at the replicat site, the replicat process would abend, which is good (for now).

You would see something like what is below

2012-04-03 21:33:22  WARNING OGG-01432  Oracle GoldenGate Delivery for Oracle, atlrep.prm:  Aborted grouped transaction on 'ATL.INVENTORY', Filter not passed.
2012-04-03 21:33:22  WARNING OGG-01003  Oracle GoldenGate Delivery for Oracle, atlrep.prm:  Repositioning to rba 10304 in seqno 6.
2012-04-03 21:33:22  WARNING OGG-01155  Oracle GoldenGate Delivery for Oracle, atlrep.prm:  Filter not passed: user error 20000 mapping CMH.INVENTORY to ATL.INVENTORY.
2012-04-03 21:33:22  WARNING OGG-01003  Oracle GoldenGate Delivery for Oracle, atlrep.prm:  Repositioning to rba 10304 in seqno 6.
2012-04-03 21:33:22  ERROR   OGG-01296  Oracle GoldenGate Delivery for Oracle, atlrep.prm:  Error mapping from CMH.INVENTORY to ATL.INVENTORY.
2012-04-03 21:33:22  ERROR   OGG-01668  Oracle GoldenGate Delivery for Oracle, atlrep.prm:  PROCESS ABENDING

However, all I ever found was how to calculate what the quantity should be (the actual math) if it were to be handled correctly by a conflict resolution process. I could never find the actual syntax to actually set up the conflict resolution rule!!

As a result, I decided to use a COLMAP, which both detects the conflict, and applies the fix if needed. This is shown below. Please note that if you use this, you don’t need the MAP entry I have above for conflict detection. This replaces it.

map CMH.INVENTORY, target ATL.INVENTORY, &
sqlexec (id INVENTORY_check, on update, &
query "select quantity from ATL.inventory where ID = :p1", params (p1 = ID)), &
COLMAP (usedefaults, &
        quantity = @if (before.quantity <> inventory_check.quantity, &
             @compute(quantity - (before.quantity - inventory_check.quantity)), &
             quantity)
       );

All this does is apply the values found in the replicat trail file for all columns with the exception of quantity. For this column, it determines if the pre-update version in the target replicat database is the same as the pre-update value was in the source extract database. If it is, it just replicates the inventory value provided in the trail file. If it doesn’t match (a conflicting update occurred at the target between the update at the source and the time the target tried to process it from the replicat), it dynamically calculates what total inventory should be based on the fact the net of the two transactions should increment or decrement inventory by the combined amounts. This replaces what is found in the replicat trail file. As noted, this both detects the conflict and handles it.

Our next post will show how to handle something like this using a stored procedure.

I hope this helps someone!

EDIT:

Technically, you don’t even have to check if the values match. You could run the update and just assume the values don’t match, as the update statement will do the correct thing, anyway.

You can use what is below:

map CMH.INVENTORY, target ATL.INVENTORY, &
sqlexec (id INVENTORY_check, on update, &
query "select quantity from ATL.inventory where ID = :p1", params (p1 = ID)), &
COLMAP (usedefaults, &
        quantity = @compute(quantity - (before.quantity - inventory_check.quantity))
       );

ORA-12516 – Possible causes

Steve — Wed, 28 Mar 2012 17:04:15 +0000

At least one is when your processes parameter in the database instance(s) has/have been exceeded.

java.sql.SQLException: Listener refused the connection with the following error:
ORA-12516, TNS:listener could not find available handler with matching protocol stack
 
        at oracle.jdbc.driver.T4CConnection.logon(T4CConnection.java:451)
        at oracle.jdbc.driver.PhysicalConnection.(PhysicalConnection.java:535)
        at oracle.jdbc.driver.T4CConnection.(T4CConnection.java:218)
        at oracle.jdbc.driver.T4CDriverExtension.getConnection(T4CDriverExtension.java:29)
        at oracle.jdbc.driver.OracleDriver.connect(OracleDriver.java:528)
        at oracle.jdbc.pool.OracleDataSource.getPhysicalConnection(OracleDataSource.java:401)
        at oracle.jdbc.pool.OracleDataSource.getConnection(OracleDataSource.java:288)
        at oracle.jdbc.pool.OracleDataSource.getConnection(OracleDataSource.java:205)
        at stressRetail.run(stressRetail.java:82)
        at java.lang.Thread.run(Unknown Source)
Caused by: oracle.net.ns.NetException: Listener refused the connection with the following error:

Java date difference in milliseconds

Steve — Wed, 28 Mar 2012 13:52:20 +0000

Every time I need to do math on a date in java, I end up googling it. While that isn’t the worst way to do things (hey, it’s probably how you found this ), I wanted something I *knew* would be there. I know there are libraries out there for this, but I usually want something very simple like, “run this in a loop for 60 seconds”. Here is what I use…

long START_TIME = new java.util.Date().getTime();
while (new java.util.Date().getTime() - START_TIME < 60000) {
  //do something
}

I don’t know how efficient the getTime() method is, but this works. You could also use System.currentTimeMillis()…

long START_TIME = new java.util.Date().getTime();
while (System.currentTimeMillis() - START_TIME < 60000) {
  //do something
}

My guess is this is more efficient. One of these days I will test it.