@xdirewolfx, Well, there is always a choice, any Hollywood movie will tell you that :)
It all really comes down to two things: 1. Transaction Management 2. Decoupling your persistence from Drools Flow persistence 1. Transaction Management If you already have Spring + Hibernate working app with all the AOP or annotational TX in place, that would mean that at run time you already have those proxies ( Spring TX ones ) that guard certain methods of your entities. Now you are plugging in the Drools Flow. You would still need to have a simple "persistence.xml" for Drools Flow tables ( 3 to 5 tables ), that has Hibernate as your provider + you would reuse your existing JTA transaction manager. Now we are smoothly transitioning to the second part.. 2. Decoupling your persistence from Drools Flow persistence The most interesting part about Drools Flow is of course suspending and resuming later functionality, or what "they" refer to as a "long running process". What really happens is, whenever you have a work item ( or an Activity, if we are talking BPMN2 ), it has a custom handler attached to it. Whenever a process ( flow ) get to this work item, it delegates its processing to this handler. Now, the handler have a choice to either complete this work item, or "let it be". And in case of the latter, since the work item is not completed, the process ( flow ) goes to sleep or.. suspends. There are certain Drools tables ( WorkItemInfo and ProcessInstanceInfo ) that will have a snapshot of this last alive point before the flow went to sleep. And here you have a dilemma.. If you have a strictly non-JPA policy, you can simply call your DAOs ( or the new, "cool" way to call them.. Repositories ) from within this handler, so everything that needs to be persisted will be. The only problem with this approach is resuming, since now when you reload the process, you need to restore that same state ( of your entities that Drools did not take a part in persisting ). But remember in order to resume the process, you need to COMPLETE that activity that is waiting to be completed, so what you can do you can reload those entities, and pass them back as a map ( "results" ) on this Activity completion. If you really want to get clever, you can hook up your persistence services to something that is called "variable persistence", where you write your own Drools Variable Persister, which calls your services to persist your entities automatically when the flow / process goes to sleep, and reloads them when the process resumes, but that is whole other can of worms :) The idea here was to give you a perspective, and to show that yes, you still have a choice :) /Anatoly -- View this message in context: http://drools-java-rules-engine.46999.n3.nabble.com/Drools-Flow-Persistence-with-Spring-Hibernate-tp834330p863725.html Sent from the Drools - User mailing list archive at Nabble.com. _______________________________________________ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users