| Subject | Re: [firebird-support] Transaction Rollback Election on deadlock |
|---|---|
| Author | Helen Borrie |
| Post date | 2009-09-24T10:34:13Z |
At 07:11 PM 24/09/2009, you wrote:
Deadlocks are rare. Most "deadlock" exceptions are not deadlocks at all, but one of a variety of lock conflict conditions. A lock conflict happens when a transaction attempts to write a new version of a record that another transaction is already updating in its own isolation space. The kind of conflict that occurs depends on how the transaction is configured: isolation level, the wait/no wait policy and, for transactions with ReadCommitted isolation, the lock resolution strategy. To know what kind of lock conflict has occurred, your app should read the lower level ISC code and respond appropriately.
The WAIT policy is important (although not more important than the other attributes!) From Fb 2.0 onward, you can configure how long a WAIT transaction will wait before being transformed into a NO WAIT one. Depending on what the clients need to do AND of course on whether you are using an interface layer that supports the transaction timeout, it could provide what you're looking for.
./heLen
>Hi Community!That's true only if your application rolls the transaction back. Firebird doesn't start or terminate user transactions.
>
>When a deadlock occurs, the newest transaction is cancelled.
>Is it possible to tell firebird to cancel the other one of the deadlock (the older one) to be rolled back?No; because Firebird doesn't roll back a transaction until the application tells it to.
>Or allows the OAT concept nothing else?It isn't about what "the OAT concept allows".
Deadlocks are rare. Most "deadlock" exceptions are not deadlocks at all, but one of a variety of lock conflict conditions. A lock conflict happens when a transaction attempts to write a new version of a record that another transaction is already updating in its own isolation space. The kind of conflict that occurs depends on how the transaction is configured: isolation level, the wait/no wait policy and, for transactions with ReadCommitted isolation, the lock resolution strategy. To know what kind of lock conflict has occurred, your app should read the lower level ISC code and respond appropriately.
>For WebDevelopment, this would be a better approach.Keep in mind that lock conflicts are MEANT to happen. By understanding how each combination of configuration settings works, you will be able to write your web applications in such a way that you get the behaviour you want when conflicts occur. Get to grips with why each sort of conflict occurs and work out what configuration your transactions will need to a) minimise them and b) resolve them.
The WAIT policy is important (although not more important than the other attributes!) From Fb 2.0 onward, you can configure how long a WAIT transaction will wait before being transformed into a NO WAIT one. Depending on what the clients need to do AND of course on whether you are using an interface layer that supports the transaction timeout, it could provide what you're looking for.
./heLen