On Mon, 29 Aug 2011 23:34:21 +0200, Roman Rokytskyy <ro...@rokytskyy.de> wrote: > 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. Yes, I indeed saw that. I didn't understand all the details yet though. > 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. Another issue here is that when a non-recoverable error > happens (e.g. request synchronisation error), we have to kill all > transactions that belong to that attachment, even if only one is in > trouble. Yes, that is one of the things I am having troubles with. Especially that units of work for the same XID should be allowed to interleave on different connections or even join simultaneously. I have seen some indications that some XA implementations simply consider the connection to be the ResourceManager, and will always respond false on isSameRM() if the argument is not the same connection. This is against the JDBC spec that XAResources from the same DataSource should be the same ResourceManager. Some will simply throw an error on a start() with TM_JOIN or TM_RESUME (see: http://frankkieviet.blogspot.com/2010/01/how-to-enlist-and-delist-xa-resources.html ) > 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. :) I will probably need to study the current implementation some more, maybe the questions I am asking right now have already been addressed in a way I don't fully understand yet. I also saw some oddities regarding (local)transaction management on the connection, if that same connection is currently involved in a distributed transaction. Mark ------------------------------------------------------------------------------ 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
