> On 27-8-2011 14:01, Vlad Khorsun wrote:
>>> I am currently going over the XA implementation in Jaybird, and this
>>> prompted some questions regarding transactions, connections and
>>> two-phase commit in Firebird.
>>>
>>> First of all: are transactions associated with the connection that
>>> created it, or is it possible to 'share' the same transaction handle
>>> with different connections? In other words: Can I use a single
>>> transaction handle for multiple connections that are enlisted in the
>>> same distributed transaction?
>>
>> When you start distributed transaction, you pass handles of all
>> participated attachments and got single common handle of distributed
>> transaction. This handle is valid within every attachments above.
>
> What if I don't know all attachments that will be involved in the same
> distributed transaction when the first attachment is enlisted? It looks
> like it would be impossible to enlist an attachment later on.
And we are going to address this issue in FB3, as i told below :)
>> In FB3 we are going to implement additional API call to join two or
>> more pre-existing transactions. It will return new handle of new distributed
>> transaction, iirc.
>
> Wouldn't it be better to join a new attachment to an existing
> distributed transaction?
No. Attachment *itself* can't participate in distributed transaction. At
least
not directly. Transaction of this attachment - can. Just understand: attachment
*is not a* transaction.
When i tell "attachment participate in distributed transaction" i mean "some
transaction of given attachment is a part (or sub-transaction) of given
distributed
transaction".
> As far as I can see in the XA specification[1],
> having a pre-existing transaction join a new distributed transactions
> would be incorrect.
Could you point me at exact place in 94-page document ? ;) I suspect XA spec
implicitly mixed terms "transaction" and "attachment" as most DBMS allows just
one active transaction per attachment...
>>> Second: if I read the IB6 ApiGuide.pdf correctly, then a single
>>> connection can have multiple transactions open in parallel, is that a
>>> correct interpretation?
>>
>> Yes. And this is unique feature of IB\FB.
>
> Ok, so this would essentially mean that a single attachment could be
> involved in multiple distributed transactions at the same time. Are
> there any gotchas with doing that?
None that i know.
>>> Third: Can Firebird handle enlistment of multiple transaction handles in
>>> a single two-phase commit, or would this require using a single
>>> transaction handle for a single transaction branch?
>>
>> Not sure i understand you correctly... Attachment could participate in
>> few separate distributed transactions at the same time (if this was your
>> question).
>
> This is essentially restating that I would like to know if it is
> possible to have multiple attachment work as a single transaction when
> performing a two-phase commit.
Two phase commit commits exactly that (distributed) transaction which
you ask to commit. If attachment participate in more than one distributed
transactions every of them should be committed separately.
Example:
tx1 = startTran(att1, att2);
tx2 = startTran(att1, att3);
// at this point att1 participate in two separate distributed transactions
// while each att2 and att3 participate in one distributed transaction
tx1.commit
// tx2 still active
// att1 and att3 still participate in distributed transaction tx2
txc2.commit
Regards,
Vlad
PS If i understand you wrong, just keep asking. If necessary ;)
------------------------------------------------------------------------------
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
