Subject | Re: [IBO] pessimistick locking - how to remove lock after client crash |
---|---|
Author | Helen Borrie |
Post date | 2007-03-12T10:16:04Z |
At 08:40 PM 12/03/2007, you wrote:
transaction that has pending work. The TCP/IP timeout will kick in
after the configured keepalive period (default is 2 hours on Windows
and Linux) and then the server will flag the uncommitted record
versions to be deleted.
TCP/IP timeout period...in terms of productivity, it would be cheaper
to fix (or ban) the programs that are blue-screening and to do
something about clean power for the operators!
Helen
>During row edit I activate "pessimistic locking" and "sync beforeNo, because, as far as the server knows, it is just an uncommitted
>edit", which
>is doing well.
>Now some customers are reporting that after a client crash (power surge,
>blue screens) the locking is still active and they are not able to edit that
>locked row.
>Sometimes the lock is going away after some timeout but sometimes it still
>exists after 20 minutes leaving the crashed client switched off.
>I then use /etc/init.d/firebird restart to completely restart
>firebird 2.0 server to
>get of that lock.
>
>My questions:
>1. Is there a way to determine, which user or workstation has initiated a
>lock?
transaction that has pending work. The TCP/IP timeout will kick in
after the configured keepalive period (default is 2 hours on Windows
and Linux) and then the server will flag the uncommitted record
versions to be deleted.
>2. is there a way to manually release a lock in such a situation?No. If this is a frequent problem, you might look at reducing the
TCP/IP timeout period...in terms of productivity, it would be cheaper
to fix (or ban) the programs that are blue-screening and to do
something about clean power for the operators!
Helen