Oracle lag between commit and select

Question

We have an Java workflow application that uses an Oracle database to track its steps and interactions with other services. During a workflow run several insert/update/selec

Answer 1

The code snippet didn't actually include the commit.

If you are assuming/relying on the close connection doing the commit, it may not be synchronous (ie the java may report the connection as closed when it tells Oracle to close the connection, which means it may be before the the commit is completed by Oracle).

Answer 2

A possible workaround may be to use JTA transaction. It keeps your connection open "behind the scene" over multiple open/close jdbc conns. Maybe it will keep your connection on the same server and avoid this sync' problem.

UserTransaction transaction = (UserTransaction)new InitialContext().lookup("java:comp/UserTransaction");
transaction.begin();
// doing multiple open/close cxs
transaction.commit();

Answer 3

"even though the insert/update commit that ran before it completed successfully."

This suggests to me that you are issuing a commit(), and then afterwards expect to read exactly the same data again (that's repeatable read).

This suggests to me that you shouldn't be committing. As long as you want to make sure that NO OTHER TASK is able to modify ANY of the data that you EXPLICITLY EXPECT to remain stable, you cannot afford to release locks (which is what commit does).

Note that while you keep a lock on some resource, other threads will be stacking up "waiting for that resource to become available". The likelyhood of that stack being non-empty at the time you release your lock, gets higher as general system load gets higher. And what your DBMS will conclude when you (finally) issue "commit", is to conclude that, "hey, wow, this guy is finally done with this resource, so now I can go about letting all the other waiting guys try and do their thing with it (AND there is NOTHING to prevent "their thing" from being an update !)".

Maybe there are issues to do with Oracle's snapshot isolation that I'm overlooking. Apologies if so.

Answer 4

I see no commit in your code. They are most important statements in such an app so I would want to have them explicitely written every time, not relying to close() or such.

You may also have autocommit set to true by default on your connection(s) which would exactly explain the behavior (it commits after every insert/update).

Can you check, that you have commits exactly where you want them, e.g. at the end of the transaction and not before?

If there are commits when you are partially through, then you have a race condition between your threads which would also explain why there are more problems when load is bigger.

Answer 5

are use using an ORM? it might be selecting from cache and not form the db after the change.

Answer 6

This sounds like an issue with RAC, with connections to two different instances and the SCN is out of sync.

As a workaround, consider not closing the database connection and getting a new one, but reuse the same connection.

If that's not workable, then add a retry to the query that attempts to retrieve the inserted row. If the row is not returned, then sleep a bit, and retry the query again. Put that into a loop, after a specified number of retries, you can then fail.

[ADDENDUM]

In his answer, Steve Broberg (+1!) raises interesting ideas. I hadn't considered:

• the COMMIT might be anything other than IMMEDIATE WAIT
• the transaction isolation level might be anything other than READ COMMITTED

I did consider the possibility of flashback query, and dismissed that out of hand without mentioning it, as there's no apparent reason the OP would be using flashback query, and no evidence of such a thing in the code snippet.)

[/ADDENDUM]