[rules-users] JPA persistence for Drools Flow

[Kris Verlaenen]

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" <mdzaebel at web.de>
To: <rules-users at lists.jboss.org>
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
> rules-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users