Monday, January 5, 2009

XA data sources and jBPM

One handy and often overlooked feature of jBPM 3.3 is the ability to customize the services provided by the jBPM context, and even add your own. The user guide documents the feature in Chapter 6: Configuration. Services are an abstraction layer from the operational environment and allow jBPM to run standalone or inside an EJB container.

When running inside an EJB container, the message service is bound to JMS and the scheduler service to EJB timers. Some supporting enterprise beans need to be deployed for the services to work. In the Hibernate configuration the JDBC connection properties are replaced by a server-provided data source.

When your process definition makes use of the message or the scheduler service, the JMS connection factory or the EJB timer service are enlisted as resource manager in the container-managed transaction, in addition to the jBPM data source. When more than one resource manager is enlisted in the same transaction, all resource managers are conceptually required to support XA (two-phase commit) unless the last resource commit optimization is in effect.

In JBoss AS, the JMS connection factory is XA capable and poses no problems. However, the EJB timer service relies on a data source to persist timer data. The data source is by default bound to DefaultDS, a local (as opposed to XA) data source. If the jBPM data source was also local, the transaction manager would reject the second local resource and roll back the transaction. There are at least three approaches to a solution to this problem.

  1. Enable multiple resource manager enlistement
  2. Associate both the EJB timer service and the jBPM persistence to a single data source
  3. Make jBPM use an XA data source
The first two solutions require end users to modify their JBoss AS configuration. However, the aim of jBPM is to provide a seamless out-of-the-box experience. End users should not be required to alter their configuration just to get the product to work. Providing an XA data source is therefore the only viable option.

Whereas most databases provide working XA data sources, most are not as proven as the standalone JDBC driver is. All of them work in the absence of errors, but some of them do not recover properly in exceptional scenarios. The currently supported databases/drivers along with their known XA support are listed below.

XA data source: no
EJB container integration not available.

XA data source: yes
Backend does not support XA - coming in 6.0 with the Falcon storage engine.

XA data source: yes
Backend and driver support.

XA data source: yes
Backend and driver support. Distributed transactions must be enabled in the backend.

Conclusion. EJB container integration is at the mercy of the target database. Choose carefully!


Kukeltje said...

Very good article. Should become part of the docs for sure... Even I learned a lot of things (remember DBMS'es are not my cup of tea)

Alejandro said...

Ronald, I'll go ahead and take your suggestion. I'll condense the information about XA data sources in the jBPM wiki and remove the anecdotal passages which may not be relevant in a product wiki.