On Tue, 30 Aug 2011 00:17:19 +0300, "Vlad Khorsun" <hv...@users.sourceforge.net> wrote: >> The XA semantics are a bit complicated, but essentially the database is a >> Resource Manager (RM), and a distributed transaction is assigned an Xid >> by >> the Transaction Manager (eg in the case of JavaEE it could be the >> application server). If I read the spec correctly, it is expected that a >> connection to the RM can be part of the Xid (start), be requested to end >> it >> is work (not prepare / commit!), then any connection (different or same) >> to >> the RM can again part of that same Xid (start), etc. > > Up to this point i see no need in special support from the Firebird. > XID is > generated by TM, attachment details and interaction with TM is handled by > Jaybird (?).
Yes, Jaybird does take care of it right now. I am trying to find out if it is working as the XA spec needs it to, and if we are using Firebird to its fullest. >> In that system the Xid is the starting point, so joining two transaction >> together into a new distributed transaction makes no sense, as the >> Resource >> Manager (Firebird) is not the owner of the Xid, but just one of the >> entities involved in the distributed transaction. > > Yes. From the TM point of view there is no need in ability to join > local transactions > at Firebird level. So, lets forget about it :) >> Maybe it is an idea to provide an XA compliant facade for Firebird? > > I see no problem to implement such facade for any existing Firebird > version. All > necessary bits is already present in Firebird, AFAIU. > > Look at isc_prepare_transaction2() API. It could attach *any* > application-specific > message to the local transaction before actual commit. TM could pass XID + > "something > to identify this part of distributed transaction" into > isc_prepare_transaction and later read > this info back from RDB$TRANSACTIONS at recovery phase, if necessary. > And\or TM > could store above "something to identify this part of distributed > transaction" + local TxID > of every part of distributed transaction into its own storage before start > distributed commit > (to identify record at RDB$TRANSACTIONS later at recovery phase). > > Look also at isc_reconnect_transaction() API which allows to > re-connect to the in-limbo > transaction at recovery phase and finally commit or rollback it. As far as I have seen, this is already done in Jaybird. So the commit can be done from any connection, but what about the prepare? My impression from this discussion is that the prepare would need to happen from the same connection which started the transaction on Firebird, is that right? > Regards, > Vlad > > PS I'm not sure it was clear explanation, so let's discuss it... I will go over the whole discussion again later this week and come up with more questions :) ------------------------------------------------------------------------------ Special Offer -- Download ArcSight Logger for FREE! Finally, a world-class log management solution at an even better price-free! And you'll get a free "Love Thy Logs" t-shirt when you download Logger. Secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsisghtdev2dev Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
