| Subject | Re: [firebird-support] locking and unlocking tables in Firebird |
|---|---|
| Author | Helen Borrie |
| Post date | 2003-11-28T10:41:30Z |
At 12:25 PM 28/11/2003 +0200, you wrote:
don't lock tables. {{ Except in Table Stability isolation, that is. }}
IB and Fb have optimistic row-level locking. A rows is not locked until
you perform an update or delete on it. It will be locked to other
transactions, although the characteristics of the lock depend on a number
of transaction settings.
When you commit a change, in the case of an update, your version of the row
becomes the new version, and your lock disappears. When you commit a
delete, all versions of the row become obsolete. Rolling back your
transaction takes database state back to the way it was when your
transaction started.
heLen
>Interbase unlocks tables when commit is issued?It's not true of InterBase and it's not true of Firebird -- because they
>Is it the same with Firebird?
don't lock tables. {{ Except in Table Stability isolation, that is. }}
IB and Fb have optimistic row-level locking. A rows is not locked until
you perform an update or delete on it. It will be locked to other
transactions, although the characteristics of the lock depend on a number
of transaction settings.
When you commit a change, in the case of an update, your version of the row
becomes the new version, and your lock disappears. When you commit a
delete, all versions of the row become obsolete. Rolling back your
transaction takes database state back to the way it was when your
transaction started.
heLen