>> 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.
>
> This code should be already working in Jaybird since day 0 (David Jencks
> implemented it in the first version of the driver). The recovery process
> uses message to query the in-limbo transactions, is able to join them
> and is able to commit or rollback them.
Very good :)
> However, if I remember correctly, the requirement to support transaction
> independent from the attachment came from the fact that TM may be asked
> to activate a transaction that "belongs" to the attachment that is being
> currently used and is associated with a different transaction. Here we
> talk about normal processing, not the recovery process. I guess the main
> issue here is the synchronization of the wire communication, so that two
> transactions are properly interleaved and server is able to handle the
> communication.
Before v2.1 it should be able to handle it properly. Since v2.1 it must
be able to handle
it properly. I mean - it should not hung and handle "asyncronous" TM call after
processing of
current "syncronous" call on the same attachment.
> Another issue here is that when a non-recoverable error
> happens (e.g. request synchronisation error),
Hmm... is it unrecoverable error ? BTW, request synchronisation error could
happen only
at fetching records, iirc...
> we have to kill all
> transactions that belong to that attachment, even if only one is in trouble.
Even if we have to kill all transactions - what is the problem for TM ?
> But this requirement is so old, that I do not remember exact details.
:)
> The only thing I remember is that it becomes obvious when somebody
> starts refactoring the XA part (which is one of the core layers there).
> That happened to me when I refactored that code few years ago, that's
> happening to Mark right now. :)
Let's solve this puzzle together ;)
Regards,
Vlad
------------------------------------------------------------------------------
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
