On Wed, 7 May 2014 05:00:43 -0400, "Claudio Valderrama C."
<cva...@usa.net>
wrote:
>> This leads me to the questions:
>> 1) When are prepared or rolled back transactions removed from
>> RDB$TRANSACTIONS? Or are they kept indefinitely?
>> 2) Is there an alternative to removing this information?
>
> Mark, I had a second look:
>
> TRA_commit:
> if (transaction->tra_flags & (TRA_prepare2 | TRA_reconnected))
> MET_update_transaction(tdbb, transaction, true);
>
> and MET_update_transaction does this, where X is RDB$TRANSACTION:
>
> if (do_commit && (transaction->tra_flags & TRA_prepare2))
> ERASE X
> else
> {
> MODIFY X
> X.RDB$TRANSACTION_STATE = do_commit ?
> RDB$TRANSACTIONS.RDB$TRANSACTION_STATE.COMMITTED :
> RDB$TRANSACTIONS.RDB$TRANSACTION_STATE.ROLLED_BACK;
> END_MODIFY
> }
>
> Hence I assume that when the failed 2PC txn is handled manually, this
> routine is not called.
As the value of RDB$TRANSACTION_STATE is modified, I assume this code (or
something very similar) is actually called, but then the `else` branch
shown above. What does TRA_prepare2 mean here? Note that the specific
scenario that triggered my question is a transaction recovery case, where
the transaction is reconnected: transaction was prepared, but not
committed/rolled back, then the connection was abandoned/destroyed; new
connections recovers transaction and commits (or rolls back).
Mark
------------------------------------------------------------------------------
Is your legacy SCM system holding you back? Join Perforce May 7 to find out:
• 3 signs your SCM is hindering your productivity
• Requirements for releasing software faster
• Expert tips and advice for migrating your SCM now
http://p.sf.net/sfu/perforce
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
