[ http://jira.jboss.com/jira/browse/JBJTA-1?page=comments#action_12314732 ] Bill Burke commented on JBJTA-1: --------------------------------
I don't think you're idea of last resource gambit is a good idea. Besides not performing well, I don't think last resource gambit is implemented correctly. For it to work, you will have to reuse the same DB connection as the TX recovery logger and let the TX recovery logger do the commit. Right now, the commit is in the prepare phase in TransactionImpl.java. Last resource gambit should be removed entirely from the TransactionImpl code and implemented as part of a TX Recovery Log that shares the same datasource as the last resource. I'll post this on forum: http://www.jboss.org/index.html?module=bb&op=viewtopic&t=58999 > Transaction Recovery > -------------------- > > Key: JBJTA-1 > URL: http://jira.jboss.com/jira/browse/JBJTA-1 > Project: JBoss JTA > Type: Task > Reporter: Adrian Brock > > > Implement optional transaction recovery > The simplest mechanism is to do this is with a local database > using the last resource gambit where during its "prepare" it logs the XID in > a table. > If this last resource fails to commit, recovery will not find the transaction > in the table which means it will rollback the whole transaction. > This has limitations where a different local resource is required within the > transaction > but not this local database used as the recovery log. > Another implementation is a local file. Though more complicated it should > give superior > performance. > But, it does not work well with the last resource gambit, e.g. you cannot tell > whether the jdbc commit() suceeded or failed if it crashes just at the point > of this invocation > before the result is returned from the db. > The other work required: > 1) Possibly, simplify the dependencies in the JCA module so we can run the > recovery earlier. > Currently the RARs need the transaction manager at deployment time. The > recovery service needs to be an external service depending upon both the > tm and the managed connection factories. > At least this will require a GUID for the XID so we can avoid duplicates > between > unrecovered XIDs and any new XIDs created before recovery is complete. > 2) JBossMQ needs to implement XAResource.recover() -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira ------------------------------------------------------- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt _______________________________________________ JBoss-Development mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/jboss-development
