>> > 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