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.
Hope this helps,
Prashanth
James.Strachan wrote:
>
> On 4/26/07, Anthrope <[EMAIL PROTECTED]> wrote:
>>
>> There is a bug in the 4.1.1 release version of
>> DefaultDatabaseLocker.java.
>> The problem is that the result of the execution of the prepared statement
>> to
>> lock the database row is being incorrectly interpreted. This link ought
>> to
>> explain why:
>>
>> http://java.sun.com/j2se/1.4.2/docs/api/java/sql/PreparedStatement.html#execute()
>>
>> I fixed and recompiled activemq and am able to use ActiveMQ 4.1.1 with
>> MySQL
>> in Master-Slave configuration quite alright.
>
> Could you give us a clue what code you changed?
>
> --
> James
> -------
> http://macstrac.blogspot.com/
>
>
--
View this message in context:
http://www.nabble.com/Failing-to-acquire-exclusive-lock---MySQL-tf3598830s2354.html#a10251224
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
