geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Re: XA_RDONLY optimization - question
Date Thu, 11 May 2006 14:39:19 GMT

On May 10, 2006, at 10:47 PM, ludovic orban wrote:

> David,
>> 1. there's only one resource in the transaction.  Well, you can just
>> call 1pc commit on it.  As a special case, if there are lots of
>> resources, but all but the last one says it's read-only, you can just
>> call 1pc commit on the last one (skipping prepare).  I think it's
>> sort of obvious this works, and doesn't introduce any risks of data
>> loss.
> I agree on this but running the prepare calls in parallel voids the
> special case of the last resource returning read-only.
>> 2. if your last resource only supports 1pc (it's not xa) some people
>> think you can just call commit on it, and then write the prepare
>> record for the other participants: you use the result of this 1pc
>> commit to decide whether to proceed or roll back the other
>> participants.   A little thought shows that the time between the
>> completion of the 1pc commit and writing the prepare record to the
>> log is vulnerable and can result in inconsistency.  (many people
>> don't seem to realize this).
> This is what Mike calls 'Last Resource Gambit'. It's main usage is to
> allow non-XA resources to participate in 2PC, it has very little to do
> with transaction speed optimization. I personally refuse to use that
> trick since it's not ACID.
>> However, there's a trick that can make
>> it work :-)  If you store the transaction log in the 1pc resource,
>> and only do the commit as a part of writing the prepare record to the
>> log (ignoring the 1pc commit call directly to the resource) then the
>> semantics work out properly.  AFAIK Jeremy Boynes thought this up,
>> and I've implemented it in geronimo, but so far there is no testing
>> of it.
> BEA implemented this in Weblogic 9 and called it 'Logging Last
> Resource' (
> The good points of this technique are that you can use a non-XA
> resource in 2PC while staying 100% ACID and you get a slight
> performance boost if you only use 2 resources in the transaction.
> The bad points are that if you use more than 2 resources this method
> is slower than using a file based tx log and also it messes up a bit
> your DB schema since you have to create some tx log table(s) in the
> same DB schema. It also can only work if the resource is a database.
> So if I properly deciphered your email, the XA_RDONLY vote is pretty
> much useless since it only allows a 1PC optimization on the last
> resource to be prepared and only if your don't run prepare calls in
> parallel.
> Am I right ?

As far as I can tell, yes :-)

david jencks

> Thank you,
> Ludovic

View raw message