Subject | Re: Full Table Lock? |
---|---|
Author | Aage Johansen |
Post date | 2002-02-13T18:35:41Z |
Salva wrote:
I'm converting an application from DB7 to IBO. It has a very delicate
process, calculate invoices from previous delivery notes.
As one invoice is created from with 1 or more delivery notes only one user
can fire this process at a time. In DB7 I full locked
temporal tables, and that it is, only one user can fire the process.
Any idea of doing the same with Interbase? (I'm newby in C/S and InterBase).
------------------
Locking tables is hardly ever a good idea in a multiuser situation.
If one of the records can be regarded as some sort of 'master', you might
use a form of pessimistic locking by having the application (or
applications) do a (dummy) update on a field in that record - this will
'lock' that record and any other user trying to do the same will be unable
to grab the lock (just handle the exception when they try to do the
update). Now, do your updates and finally commit (or roll back) - this
will free up the lock'ed record (and thus, the whole set of records). As
you see, it will require some discipline from every program used to
calculate the invoices.
Otherwise, you may be forced to handle locking through explicit
reservations (in separate table) or explicitly 'locking' all 'interesting'
records.
Regards,
Aage J.
I'm converting an application from DB7 to IBO. It has a very delicate
process, calculate invoices from previous delivery notes.
As one invoice is created from with 1 or more delivery notes only one user
can fire this process at a time. In DB7 I full locked
temporal tables, and that it is, only one user can fire the process.
Any idea of doing the same with Interbase? (I'm newby in C/S and InterBase).
------------------
Locking tables is hardly ever a good idea in a multiuser situation.
If one of the records can be regarded as some sort of 'master', you might
use a form of pessimistic locking by having the application (or
applications) do a (dummy) update on a field in that record - this will
'lock' that record and any other user trying to do the same will be unable
to grab the lock (just handle the exception when they try to do the
update). Now, do your updates and finally commit (or roll back) - this
will free up the lock'ed record (and thus, the whole set of records). As
you see, it will require some discipline from every program used to
calculate the invoices.
Otherwise, you may be forced to handle locking through explicit
reservations (in separate table) or explicitly 'locking' all 'interesting'
records.
Regards,
Aage J.