Persistence

[tizo]

We have had some problems with persistence in Activiti. First I will describe the environment where we are using it.

Activiti is used in an EJB, which is deployed in a GlassFish server. Spring is not used. The engine is created when an instance of the EJB is created (in a method annotated with @PostConstruct); I know that probably this is a bad decision for the performance, but after finding a solution for the problem of persistence, we will try to start the Activiti engine as a GlassFish service, and obtain it with jndi.

The EJB is using JTA with CMT and JPA. Activiti on the other hand, is using it owns persistence layer, with the JDBC properties configured in activiti.cfg.xml.

The big problem that we are having, is that Activiti transactions are totally independent from the container transactions. So there are times when the container transaction is rolled back due to an error, but the Activiti transaction is happily committed.

Having all the picture in mind, I think that the two possibles solutions for our problem are (in that order):

- Making Activiti use the same Entity Manager that is used by the EJB, as it is configured with JTA. I have seen that in Activiti 5.1 User Guide, there is an example on how to use JPA. However, I think that this example is useful when JPA entities need to be handled, but not for the persistence of Activiti tables: I have tried it, and it keep asking me for org.h2.Driver. I think that if JPA was used for the entities and Activiti tables, the engine should not worry about JDBC connection, as all that it would need was the Entity Manager.

- Making Activiti use a DataSource obtained from the container (with @Resource annotation). I have tried updating a DB A with an EntityManager, and a DB B with a DataSource, and both modifications are done in the same transaction, using XA to commit them. It is important to note again that Spring is not used in our environment, and I don't know if Activiti can be configured with a DataSource from the container (without Spring).

Any suggestion?

Thanks very much.

[ronald_van_kuij]

I know that probably this is a bad decision for the performance, but after finding a solution for the problem of persistence, we will try to start the Activiti engine as a GlassFish service, and obtain it with jndi.

We currently do it in an EJB3.1 singleton… works great.

- Making Activiti use the same Entity Manager that is used by the EJB, as it is configured with JTA.

This would mean rewriting the db core of Activiti… Nice, interesting excercise, but a decent amount of work.

- Making Activiti use a DataSource obtained from the container (with @Resource annotation).

Or have the option to pass in a datasource in another way. @Resource binds you to a container, which is currently not needed. Starting it in an EJB, where you have the datasource and use that when starting the engine would be an option I think.

But there is a third wat. Have Activiti use the same transaction as the container in which a call to Activiti is made. This is still experimental though, but feedback is appreciated…Look here: http://www.activiti.org/userguide/index.html#configurationRoot

[jbarrez]

Activiti doesnt yet (fully) work with JTA. It is on the roadmap for next month I believe (have to check).

We only have a dependency on Spring for parsing our configuration. You can use that same configurtation to configure your datasource from jndi and inject it into the Activiti configuration.

[tizo]

Ronald,

Thanks, thanks, thanks! I have tried the following (having obtained the datasource with the @Resource annotation before):


        ProcessEngineConfiguration pec = ProcessEngineConfiguration.createProcessEngineConfigurationFromResourceDefault();
        pec.setDataSource(datasource);
        pec.setTransactionsExternallyManaged(true);
        engine = pec.buildProcessEngine();
And it works like a charm!!

Besides, I have tried the Singleton EJB for the engine, and it works too. I have made the tests with others DB updates (with a JPA EntityManager configured with a totally independent datasource), and have proved that both updates are committed or rolled back together (probably with two-phase commit protocol). So everything is working great.

Activiti doesnt yet (fully) work with JTA.

What do you exactly mean?. All the tests that I have made worked fine. I would like to know what could fail and in what circumstances.

Thanks very much.

[jbarrez]

What do you exactly mean?. All the tests that I have made worked fine. I would like to know what could fail and in what circumstances.

I'm sorry, I had to be more specific. Activiti does not yet support the case when Activiti is the driver of the transactions: ie Activiti starts/commits/rollbacks the JTA transaction itself. Your case is indeed covered, as you call Activiti from within a transactional context already.

[ronald_van_kuij]

Would be good to add this to the docs… I'll make a jira for this