I've thought about it a lot. Since this "optimization" normally destroys the integrity of transactions, I decided not to implement it the usual way. You can maintain transactional integrity if the last resource is also used as the transaction log and the transaction log "prepare" entries are in the same 1-phase transaction as the work on the last resource. This is implemented for a jdbc last resource but I've never figured out a plausible way to test it. Since the tx log is going to be in a jdbc database in probably a different process rather than a highly optimized tx log it is likely to be considerably slower than just using the normal log with 2-phase commit for all resources.
We also allow you to include as many 1-phase resources in your transactions as you want, but there's no way to order them to make sure the 1-phase resources are last. (Also I think things are set up so the prepare on the 1-phase resource is a no-op and the commit maps to the 1-phase commit). david jencks On Jan 12, 2012, at 7:52 AM, Florent Guillaume wrote: > Hi, > > Has there been any thought of implementing the so-called "last > resource commit optimization" in TransactionImpl.internalPrepare? > The idea is, on the last resource in the list, to avoid calling > prepare() and immediately call commit(onePhase=true). Deciding when > and which resource to put last in the list depends on a number of > factors. > > Arjuna for instance implements this optimization, but only for > resources that implement a custom marker interface. > > Thanks, > Florent > > -- > Florent Guillaume, Director of R&D, Nuxeo > Open Source, Java EE based, Enterprise Content Management (ECM) > http://www.nuxeo.com http://www.nuxeo.org +33 1 40 33 79 87
