RAC data propagation delay?

Question

Hi Experts,
I have a multi-threaded app that connects to a RAC DB using OCI.
Flow:
1.) Get an expired resource
2.) Assigned it to a user
Each thread executes the following sequence of queries:
1.) SELECT id, data FROM table_name WHERE date_expiry = :min_date AND rownum = 1 FOR UPDATE;
2.) UPDATE table_name SET date_expiry = trunc(sysdate) + 30, user = :user WHERE id = :id
3.) COMMIT;
-- :min_date is always <= trunc(sysdate)
I expect that each row will only be assigned to a unique user.
Apparently, this is not the case. It seems that some threads can still get a row even after the date_expiry has been updated.
Is there a data propagation delay between RAC nodes?
If there is, a thread can fetch a row even after another thread have updated it if the threads are connected in different nodes.
This is the only reason I can think of.
I tested this many times on a stand alone DB, but I can't replicate the error.
Please help!
BTW, our oracle version is:
Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bit Production With the Partitioning, Real Application Clusters, OLAP, Data Mining and Real Application Testing options
Edited by: user11912154 on Sep 17, 2009 3:01 AM

Answer 1

user11912154 wrote:
Each thread executes the following sequence of queries:
1.) SELECT id, data FROM table_name WHERE date_expiry = :min_date AND rownum = 1 FOR UPDATE;Bad method IMO. I have experimented with it when designing a PL/SQL replication system (Oracle SE) and this approach was not very robust and did not work properly.
A better method would be to use something like a dispatcher/thread manager that hands out the work. So instead of each thread trying to discover what work needs to be done - and running into concurrency issues - the manager process picks up a batch of work to be done and distributed that amongst threads.
Simplistic example. The thread manager fires of the SQL to find work and bulk fetches the 1st 50 rows. It closes the cursor, caches the 50 rowids and fires off 10 threads to process the 1st 10 rows. Each sleeps for a few seconds, wakes up, checks the thread number, finds that 8 threads are still busy and fires off 2 more threads to do the next 2 rowids. Repeat. When the cache has been processed (or when it is down to the last 10 rowids), the manager finds the next batch of work to do.
The key design issue is not to have threads competing to find work. As this means competing for access to the same resource, and potential serialisation issues - threads stepping on one another's toes and getting hurt.