Subject Re: Locking tables
Author mikcaau
--- In, "nagypapi" <nagypapi@f...> wrote:
> > To map around this I have a control table with (at the moment) one
> > row. Before the recurrent reservation process can run it tries to
> > update this row. If it succeeds it keeps the row lock until it haas
> > finished the Recurrent run.
> >
> > Other apps that try to update recurrents cannot get a lock on the row
> > and thus drop back to normal operations.
> Do you do a commit after updating the 1 row?
> If so, what happens if a client crashes just after commiting that 1 row?

I hold the update transaction until all the other routines have run.
I client crashes (my programs do while I am debugging :( Firebird will
detect the lost connection after a wait period - determine the
transactions that connection had and roll them back.

It is just a simple token controlled access system.
In effect the row first used is a token and client programs cannot run
until they have the token.
A final act is to change a date in that row so that other (or even
this) client won't run again until date + hysterysis is passed