>> > 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".
>
> 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.
Regards,
Vlad
------------------------------------------------------------------------------
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
