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
