Subject | Re: Locking tables |
---|---|
Author | mikcaau |
Post date | 2005-01-13T04:52:43Z |
--- In firebird-support@yahoogroups.com, "nagypapi" <nagypapi@f...> wrote:
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
Mick
>I hold the update transaction until all the other routines have run.
> > 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 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
Mick