Heikki,
Yep. That's why I use seperate connections for holding the lock and
to do the subsequent locking attempts. Besides, if that were the
problem, I would see the lock disappear at the very first failed
locking attempt, but that's not the case.
I thought it might be a connection timeout, but the settings don't
seem to allow for that (unless my debug session takes 8 hours).
Aargh, why isn't there a nice log that tells me why the lock is
released. Or is there? I remember a debug-option, do you think that
may work?
Wouter Zelle
>----- Original Message -----
>From: "Wouter Zelle" <w.f.zelle@stripped>
>
> > Unfortunately it is not that easy. I've set the
>> innodb_lock_wait_timeout to 1 because I want locks to fail quickly,
>> so my program can move on to the next request. In pseudocode:
>>
>> Fetch a bunch of requests with status=unprocessed
>> Try to obtain a lock through a select * from x for update
>> If lock: process
>> If lock-timeout: move on to the next request.
>>
>> This works perfectly except that the locks disappear suddenly for no
>> good reason at all. This takes far longer than the
>
>did you take into account that a lock wait timeout error rolls back the
>WHOLE transaction and releases ALL locks of that transaction?
>
>Regards,
>
>Heikki
--
sql, query, stupid filter