When working in enterprise environments, it is often necessary to interact with multiple resources in a single atomic unit of work - a distributed transaction. The ideal way to accomplish this is by leveraging JTA to manage the distributed transaction. However, in transaction scenarios where one or more resources do not support XA transactions JTA cannot be used. Justin McCarter and Travis Alvey describe a method of interacting with non-transactional resources in a pseudo-transaction.
Read article

Apart from using Throwable all over the place (what happens if you get an OutOfMemoryError for instance, is it valid to try and handle this because surely the VM is FUBAR at this point and tracing the problem will be a nightmare?) it's a good example of the kind of thing the Command pattern is suited for.

My company has developed an (unfortunately, because IMHO it's really good!) closed source Persistance framework. It is actually transactional, because you can rollback the changes made to the data, by snapshooting the data on change event, and restore the old data programmatically or automatically (on error while persisting, or if the business logic say that the object has invalid data)
I once wished to make it XA-compliance (it was not a real feature request, but I thougt it would be cool...) and started to read the sepcification and some tutorials.
Here is my question to the community: I could not find examples or tutorials about IMPLEMENTING XA transactions (on pojos, for example). I could only find tutorials on using transactions.
Our implementation is actually similar the one explained in the article, ie. we have a rollback method on "our" session object.
Is there a way to transform that pseudo transaction in a REAL one? A guide (book or online) on implementing XAResource?

There isn't much good documentation that we've found (I write JCA connectors that are XA or partially XA, such as an FTP Connector). Your best bet is any documentation you can find about JCA, they often have snippets of info. Application vendor documentation aimed at developers often have a Gem or two hidden away.
But indeed this is a pretty dark art :)

My company has developed an (unfortunately, because IMHO it's really good!) closed source Persistance framework. It is actually transactional, because you can rollback the changes made to the data, by snapshooting the data on change event, and restore the old data programmatically or automatically (on error while persisting, or if the business logic say that the object has invalid data)

I once wished to make it XA-compliance (it was not a real feature request, but I thougt it would be cool...) and started to read the sepcification and some tutorials.

Here is my question to the community: I could not find examples or tutorials about IMPLEMENTING XA transactions (on pojos, for example). I could only find tutorials on using transactions.

Our implementation is actually similar the one explained in the article, ie. we have a rollback method on "our" session object.

Is there a way to transform that pseudo transaction in a REAL one? A guide (book or online) on implementing XAResource?

Actually it's not entirely true that you cannot use JTA unless all participants are XA-aware. Quite a few JTA implementations offer optimizations where one participant, at most, can be a non XA RM participating in a 2pc transaction. The trade-off is you give up *reliable recoverability*. Optimizations such as last agent commit are not that uncommon and implemented in JTA implementations in the major app servers.
As for information about the black art of JTA/JTS see the book 'Java Transaction Service' by Mark Little and co. An outstanding reference straight from the horse's mouth.

Actually it's not entirely true that you cannot use JTA unless all participants are XA-aware. Quite a few JTA implementations offer optimizations where one participant, at most, can be a non XA RM participating in a 2pc transaction. The trade-off is you give up *reliable recoverability*. Optimizations such as last agent commit are not that uncommon and implemented in JTA implementations in the major app servers.

As for information about the black art of JTA/JTS see the book 'Java Transaction Service' by Mark Little and co. An outstanding reference straight from the horse's mouth.

And actually it's not entirely true that there's trade-off where "you give up *reliable recoverability*" when there's a single non-XA participant in an XA transaction. WebLogic Server, OC4J Application Server, and WebSphere provide an enhancement to the last agent commit optimization that yields fully ACID transactions when a transaction has 1 or more XA capable participating resource plus a single non-XA capable JDBC resource.
In WebLogic, the feature is fairly transparent - it's a checkbox on the JDBC datasource configuration - and is called "Logging Last Resource". It's documented here Understanding the Logging Last Resource Transaction Option and here Logging Last Resource Transaction Optimization.

Thanks for the information, Tom - I wasn't aware of LLR! I have a question - what happens when the local transaction commits but the app server/network crashes before the response from the non-XA resource is received? When the app server comes back up how does it know the non xa resource actually committed?
Btw, where is Zach these days? I still remember some of the WLS JMS internals presentations he had made for the various engineering support teams - they were awesome!

Thanks for the information, Tom - I wasn't aware of LLR! I have a question - what happens when the local transaction commits but the app server/network crashes before the response from the non-XA resource is received? When the app server comes back up how does it know the non xa resource actually committed?

I think this is already somewhat covered in the doc links:

Under the covers, the LLR participant "secretly" inserts a transaction record into a database table as part of the internal JDBC local transaction - unbeknown to the calling application. During a crash recovery, the transaction manager communicates with the LLR participant in order to discover the status of in-doubt transactions. If the transaction record exists, the XA participants of the transaction are committed; if it doesn't these participants are rolled back.

Btw, where is Zach these days? I still remember some of the WLS JMS internals presentations he had made for the various engineering support teams - they were awesome!

Zach's moved on to different pastures - I haven't been in touch with him recently.

TechTarget provides technology professionals with the information they need to perform their jobs - from developing strategy, to making cost-effective purchase decisions and managing their organizations technology projects - with its network of technology-specific websites, events and online magazines.