Enlisting resource in a JTA Tx that isn't 2PC-aware

[alrubinger]

Hi guys:

I've been using a document- and graph-oriented DB called OrientDB.  The impl *does* support transactions, but does not support a prepare phase. 

Now, I'd like to enlist it as a resource in a JTA transaction managed by a proper TM, but the only way I know to do this is to implement XAResource and enlist that.  XAResource, of course, is designed for 2PC, which isn't supported by the underlying DB impl.

So I can:

1) Perform the DB commit in the XAResource "prepare" method and throw an exception if no good? (Hack)

2)  Same as above but in the "commit" method (Worse hack, I think)

3) Do something entirely different which I haven't yet considered?

For instance should I instead be implementing a single-phase LocalTransaction in JCA and then using it only with local Tx and this would stay unsupported by a TransactionManager?

Appealing to your expertise here, guys.  Thanks!

S,

ALR

[robert.panzer]

Hi Andrew,

I would not try to mimic 2PC as it will never work with the same reliability.

Instead I would go for LocalTransaction.

WebSphere has a feature called Last Participant Support that allows to add one 1PC resource into a transaction with multiple 2PC resources, committing the 1PC resource after prepare and committing the other resources if the commit to the 1PC resource succeeds and rolls back otherwise.

I bet that JBoss has something similar. ;-)

KInd regards

Robert

[alrubinger]

Yeah, this confirms my feelings on the matter.  JBoss equivalent is LRCO[1][2]  I'm gonna opt for an underlying DB which supports a "prepare" phase.

Thanks.

S,

ALR

[1]Development Guide

[2]https://access.redhat.com/site/documentation/en-US/JBoss_Enterprise_Application_Platform/5/html/Administration_And_Configuration_Guide/lrco-overview.html

[paul.robinson]

Andrew,

I appreciate that you have now moved on, and don't need this anymore. However, I'll reply anyway, so that others in your position can benefit and incase you change your mind...

You have two options:

1. LRCO (as you and Robert suggest). This is quite simple for you to implement, but does have a failure window which can leave the transaction in an inconsistent state. This happens if a failure occurs after the TM informs the one phase resource to commit, but before it hears back if it was successful. In this case the TM can't find out what happened to the one phase resource during recovery.

2. Commit Marker Resource (CMR). This is a new Narayana feature that allows a single 1 phase resource to be enlisted in the transaction and doesn't exhibit any failure windows. The crux of the protocol is that some transaction data is committed in the same local transaction as the business logic's update to the one-phase resource. The TM can look for this data at recovery time to see if the local transaction committed or not. The down-side is that it's harder for you to implement than LRCO. I'm not sure that CMR is documented yet, as it's a very new feature. tomkins: is it documented yet?

Paul.