@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-Persisten...
Sent from the Drools - User mailing list archive at
Nabble.com.