> On Sat, 10 May 2014 13:46:46 +0300, "Vlad Khorsun" wrote:
>> Surprise : after you got list of tx numbers it can be used to query
>> RDB$TRANSACTIONS for additional info.
>
> But then I could just as well query RDB$TRANSACTIONS directly. I don't
> know the Firebird transaction id: I need to identify it by the Xid I
> receive from the transaction manager.
Sure. But you ask for a way to not query ALL records in RDB$TRANSACTIONS -
here it is.
>>> Of course I can also query RDB$TRANSACTIONS with RDB$TRANSACTION_STATE
> =
>>> 1,
>>> but in the future I may also need to know if a Xid is already committed
>>> or
>>> rolled back (although the current code doesn't do that).
So, you need mapping Xid -> TxID.
>> When you call commit\rollback after reconnect, engine updates
>> RDB$TRANSACTION_STATE correspondingly.
>
> I know that, but it is about obtaining that information. I also need to be
> able to provide information to the transaction manager if he requests the
> recovery of a Xid that has already been committed (eg because between the
> actual commit on Firebird and confirmation to the transaction manager an
> exception could occur (or the application might go down). In that case the
> transaction manager will at a later time ask Jaybird to recover the
> transaction and retry the commit or rollback and the XA standard prefers to
> have correct feedback on the transaction state.
So, you need mapping Xid -> TxID even more :)
>> If repair failed at some another host (i.e. some participants was
>> committed\rolled back and
>> some was left in limbo), you will be able to try repair again, starting
>> from that host. I hope you
>> put info about all participants into RDB$DESCRIPTION (as fbclient does)
>> along with Xid ?
>
> In the case of Jaybird we are not following the distributed transaction
> model of Firebird, we are following the distributed transaction model of
> the XA standard and JTA (Java Transaction API). In that situation, Jaybird
> is only a Resource Manager (and the firebird database the resource being
> managed), while the whole distributed transaction is coordinated by a
> Transaction Manager (which is usually a JavaEE application server).
>
> The Xid contains information about the global transaction identity and the
> transaction branch id (both assigned by the global transaction manager).
> Jaybird does not know about the other participant (not even if all other
> participants are also Firebird database managed by Jaybird).
Again, you need mapping of global Xid to local TxID. What prevents you
from maintaining it in special table ?
Regards,
Vlad
------------------------------------------------------------------------------
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
