On Sun, 28 Aug 2011 18:20:31 +0300, "Vlad Khorsun" <hv...@users.sourceforge.net> wrote: >> Certainly, we can make API look like we _do_ join a new attachment to an >> existing distributed transaction. To do so we just start new transaction >> in API call internally (need to know TPB...) and join it with existing >> distributed transaction. But I see no '+' in this approach compared with >> joining 2 transactions into new distributed transaction. > > I also see no reason to make such unclear hack.
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. And finally the RM specific work of the distributed transaction should be preparable and commitable by any connection to the RM. 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. Maybe it is an idea to provide an XA compliant facade for Firebird? ------------------------------------------------------------------------------ EMC VNX: the world's simplest storage, starting under $10K The only unified storage solution that offers unified management Up to 160% more powerful than alternatives and 25% more efficient. Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
