> 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 (?).
> And finally the RM
> specific work of the distributed transaction should be preparable and
> commitable by any connection to the RM.
This is where Firebird support is necessary. Below i'll show that it is
already
present in the engine.
> 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.
Regards,
Vlad
PS I'm not sure it was clear explanation, so let's discuss it...
------------------------------------------------------------------------------
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
