| Subject | Re: [firebird-support] What I am missing in the transaction ? |
|---|---|
| Author | Mark Rotteveel |
| Post date | 2018-09-24T16:11:07Z |
On 24-9-2018 17:35, blackfalconsoftware@... [firebird-support]
wrote:
driver, the default is NO WAIT.
erased record". But he did not get an error. Which suggests an order of
transactions and operations that will not yield an error.
The error "cannot update erased record" is an actual error in Firebird
(error code 336527548), but I'm not actually sure how it can be
triggered. Maybe with a positioned update on a named cursor, but even
then that would only happen if the updating transaction was started
before the deleting transaction has been committed.
If the deleting transaction has been committed before the updating
transaction was started, it will be as if the record never existed, so
there will be no error, which is the most likely explanation of the
problem observed by the OP.
Unless the problem is that the first transaction has not been committed
yet, in which case the second transaction is still waiting, and the
error will only occur once the first transaction completes.
commit mode). A rollback will always need to be explicitly initiated.
Mark
--
Mark Rotteveel
wrote:
> The WAIT option forces a transaction to stop processing if a conflictThat depends on the client (and/or driver). For example for the ADO.net
> occurs with another transaction. This in essence forces transactions to
> become single-threaded in a simplified manner. It is also the default
> mode in Firebird.
driver, the default is NO WAIT.
> The SNAPSHOT TABLE STABILITY option, which you suggested, appears to beAs I already mentioned.
> overly restrictive for the majority of transactional conflicts.
> In the case of the initial issue, the developer required a technique toNo, the OP assumed that what he did would yield an error "cannot update
> yield an error if an exception occurred in an attempt to delete a record
> when it no longer existed. At least that was my understanding of the query.
erased record". But he did not get an error. Which suggests an order of
transactions and operations that will not yield an error.
The error "cannot update erased record" is an actual error in Firebird
(error code 336527548), but I'm not actually sure how it can be
triggered. Maybe with a positioned update on a named cursor, but even
then that would only happen if the updating transaction was started
before the deleting transaction has been committed.
If the deleting transaction has been committed before the updating
transaction was started, it will be as if the record never existed, so
there will be no error, which is the most likely explanation of the
problem observed by the OP.
Unless the problem is that the first transaction has not been committed
yet, in which case the second transaction is still waiting, and the
error will only occur once the first transaction completes.
> There is no reason why a transaction in this case cannot be simply setTransactions in Firebird never automatically rollback (ignoring auto
> up to either yield an error so that ADO.NET can per form a rollback or
> do so in a manner that the transaction itself performs a rollback.
commit mode). A rollback will always need to be explicitly initiated.
Mark
--
Mark Rotteveel