geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ludovic orban" <ludovic.or...@gmail.com>
Subject Re: XA_RDONLY optimization - question
Date Thu, 11 May 2006 05:47:15 GMT
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' (http://edocs.bea.com/wls/docs90/jta/llr.html).
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 ?

Thank you,
Ludovic

Mime
View raw message