On 4/30/07, Anthrope <[EMAIL PROTECTED]> wrote:
Sure. Apologies for not providing that up-front; I had just hacked up a
solution in order to get on. Anyway, I found that there was an issue was on
line 59 in DefaultDatabaseLocker.java:
boolean answer = statement.execute();
if (answer) {
break;
}
I believe that when you run the "Select for update", the behaviour is for
control to return to the caller even if the call did about the return value
from PreparedStatement.execute(): "true if the first result is a ResultSet
object; false if the first result is an update count or there is no result"
We need to interpret answer correctly, and for sheer expediency, I simply
changed the logic to always break upon returning from the call to execute().
The first one to acquire the lock always breaks, and the others simply wait,
and upon successfully acquiring the lock, break out of the loop.
Thanks for the patch! We applied this some time ago to trunk, but it
looks like it wasn't back ported to 4.1.1. I've just updated the 4.1
branch so the next 4.1.x release will have this patch applied. Many
thanks.
--
James
-------
http://macstrac.blogspot.com/
