[jbpm-dev] [Design of JBoss jBPM] - Re: Any possibility of persistence-API?

anonymous wrote : A 'good' practice is to not store domain data in your workflow engine and just store references. It is possible then (afaik) to use both frameworks (hibernate and iBatis) side by side then by using XA datasources... and a JTA transactionmanager. So the real need is not that high imo. | The issue with this (and for us its been a big issue) is the subsequent inability to update then read the same table row in one XA when the row is updated by one persistence mechanism and then a read attempt is made by the other. (This generates a deadlock in the DB.) Scenario: * A Business domain uses the container's JPA. jBPM uses Hibernate, so we're using two different persistence architectures. | * User completes a task via an application in the business domain. The action updates a series of domain objects based on data recorded from the screen and then calls a jBPM service to advance the process. | * A jBPM process executes and at some point needs to read data from one of the domain tables that were updated earlier. (A jBPM process may traverse multiple decision trees and launch multiple points of integration and/or child processes, so that it may be impractical to try to consider exactly what all might be part of this big XA transaction.) | * The database will deadlock since the original update to the table won't commit till the entire XA commits. However, the XA won't commit till the read is complete, and the read is waiting for the update to commit. | | If both domains were using the same persistence architecture (the same persistence unit), we'd be using the same JTA transaction and the same DB connection, and there would be no deadlock. | | This problem can be overcome in one of three ways that I can see: * Use a single persistence unit on a single server for both the domain and jBPM. | | * Enlist jBPM (Hibernate) in the same JTA transaction that was started via JPA. Anyone know how to readily do this? | | * Put the domain application and jBPM on separate servers, using a JMS (or similar) interface between the two. This ensures (mostly) that the domain transaction can complete ahead of any jBPM transaction and vice-versa. Of course, if your process does lots of back and forth with your domain objects, this is going to get pretty heavy pretty fast--don't forget to make provisions for rolling back each call. You had better be good at writing a solid framework to handle it, or you're going to lose your sanity. | | These solutions really reflect two simple strategies. When it comes to persistence, either get your domain and jBPM completely together, or keep them completely apart. Any in-between is a recipe for eventual trouble. Unfortunately, in its current incarnation, jBPM doesn't make either of these solutions readily available--you can't readily switch out the persistence mechanism, and jBPM doesn't provide a viable JMS interface. | | To date, we've been able to side-step, hurdle, or otherwise work around these deadlock issues as they arise, but it's truly been a mine field for the designer (me, in this case). Am I just missing something really simple here? | | Of course, the impetus to break out jBPM's persistence mechanism is lessened since future versions will be based on standard JPA, but the above concerns are applicable to anyone using the 3.x branch--which is basically every jBPM user at this point. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4204088#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...