|
On 2014-11-25, 10:38 AM, "OC" wrote:
Chuck,
thanks a very big lot!
There are no simple solutions. You need to be aware of where this can happen in your app and code for it.
A thorough refactoring is exactly what I would very much like to do :)
Alas, most of the current code is pretty old, written years ago with a firm intention to run single-instance (and even without WOAllowsConcurrentRequestHandling), and before I get the time to re-write the guts and do it right, I must make the current
thing at least _somewhat_ stable and useable.
We have all been there.
When I get the "condition 379. Optimistic locking: multiple transaction conflict detected" I do essentially nothing -- I just wait a random couple of tenths of second, and retry.
I have seen that, but very rarely. If all of the connections to the data base use "/isolation=read_committed/locking=optimistic” you should not get this. I have caused this by using FrontBase Manager or some other tool to look at the database as it used
a different isolation level and / or (don’t recall) locking
I might be wrong, but I believe it happens whenever two separate instances happen to update both before they commit, e.g., A: update, B: update (same row), A: commit, B: commit.
Hmmm, you could be right. I was thinking you would get an optimistic locking exception but if the transactions happened in the same instant, you would get this.
Depends on the application logic how probable this is, but I believe in principle it can always happen, and I believe if it does, in this scenario -- with the "TRANSACTION ISOLATION LEVEL read committed, LOCKING optimistic" setting in both sessions --
the latter commit consistently yields "Exception 379. Optimistic locking: multiple transaction conflict detected".
It happens to me occassionally; far as I can say, the isolation level is all right. Of course, I may be wrong, as always.
In that case, the detection of optimistic locking exceptions in Wonder needs to be extended to consider this the same as the WHERE clause failing to match.
By the way, leads me to another question -- is there a way to send SQL and read the result string? I actually wanted to send "show transaction;" and put the result to my application log, to be sure the setting works on the production server (where I can't
check through FBManager). I have found I should be able to use ERXEOAccessUtilities.evaluateSQLWithEntity(Named) to send the SQL, but I can't see how to obtain the results?
Not at the EOF level, no. The only code that gets a result expects a row based ResultSet. Show transaction is a FrontBase sql92 specific command, IIRC. You should be able to drill down into the JDBC Connection object in the app to log out what the settings
are.
Chuck
|