activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Anthrope>
Subject Re: Failing to acquire exclusive lock - MySQL
Date Mon, 30 Apr 2007 10:25:23 GMT

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

 boolean answer = statement.execute();
                if (answer) {

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,

James.Strachan wrote:
> On 4/26/07, Anthrope <> wrote:
>> There is a bug in the 4.1.1 release version of
>> 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:
>> 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
> -------

View this message in context:
Sent from the ActiveMQ - User mailing list archive at

View raw message