Marc,
As Mauricio already pointed out, we have already have very concrete plans in
adding separate persistence of process instance variables in the database.
I expect this to be added to trunk in a few weeks time. This will allow
pluggable persistence managers for all your variables based on the type of
the variable (class or annotation). By default, we will include support for
simply storing the value directly and support for JPA entities (as they are
already stored separately), with the possibility to register other
strategies.
As you also noticed correctly, persistence is implemented orthogonally.
This means it is indeed possible to completely replace the persistence with
your own. We do however try to provide the most common feature requests out
of the box, and you're lucky as separate variable persistence is one of them
:)
Another strategy that might be useful in a lot of use cases (not sure what
yours is exactly so not sure it applies) is not querying on the runtime
database but getting the information from the history logs. The drools-bam
module for example shows how information about all running process instances
(their state, which nodes were triggered, etc.) can be stored in a database.
As this is implemented based on the generic listener interface, you can use
this to create a persistent log of information using the model that suits
your use cases. Notice that a history log is not only about completed
process instances, but about currently executing ones as well. The
advantage of this approach is that queries on the history log won't ever
impact your running sessions and you can define what data to store yourself
(and how), optimized to your use case.
Kris
----- Original Message -----
From: "Marc Dzaebel" <[email protected]>
To: <[email protected]>
Sent: Tuesday, April 07, 2009 12:30 AM
Subject: [rules-users] JPA persistence for Drools Flow
Hi,
w're evaluating Drools Flow 5 as a process engine for bigger projects at
Volkswagen in a world wide szenario.
There is one crucial question about process persistence. Process instances
are currently saved binary (@LOB) via ObjectOutputStream and
ByteArrayOutputStream through JPA. May be this is efficient for
persisting,
however, it disables ordinary database access. E.g. if you use process
variables and need to find a certain process instance with some process
variable values we'd need to unwrap each process for a detailed access.
For
100000 processes in the database this might be too slow as Java needs to
load all instances for access.
We could save process data redundantly via ordinary JPA queries but this
could be dangeous. It would be a rewrite of process persistence. Is there
a
plan to extend the persistence strategy to allow ordinary database access
via JPA (no LOBs)?
In our current szenario we would have to wrap orders into a process that
is
persisted. Of course we'd need to search for older input during the
process
directly in the database.
Thanks in advance
Marc
--
View this message in context:
http://www.nabble.com/JPA-persistence-for-Drools-Flow-tp22918819p22918819.html
Sent from the drools - user mailing list archive at Nabble.com.
_______________________________________________
rules-users mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/rules-users
_______________________________________________
rules-users mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/rules-users
