geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Re: txmanager last resource commit optimization
Date Thu, 12 Jan 2012 16:30:03 GMT
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

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)
>   +33 1 40 33 79 87

View raw message