[rules-users] Maintaining DB/Working Memory Synchronization

Andrew Waterman andrew.waterman at gmail.com
Sat Nov 7 11:04:52 EST 2009


I neglected to mention my reply is from the viewpoint of changing entities
through the program that interacts with drools; if you need to sense changes
from another source to entities/tables in a database Greg's suggestion seems
the easiest and least resource intensive.  Pushed actions from the database
into rules would be more efficient; but this begs the question as to where
working memory is held; are you thinking of REST calls to a Drools rules
server Greg?

best wishes,

Andrew

On Sat, Nov 7, 2009 at 9:59 AM, Andrew Waterman
<andrew.waterman at gmail.com>wrote:

> It can depend on how you want to use working memory as well.  If you are
> working statelessly, you can load objects through some type of transactional
> framework, insert them into memory (or the ones relevant to you at that
> moment in time) let Drools evaluate the objects, make changes and then
> serialize those changes once rules have stopped firing.  I do something like
> this using EJB and JPA.  I've been interested in pushing this into the rules
> themselves; which I believe is now possible using the JPA support within
> Drools flow.  This might work much better if you were using statefull and
> long running working memory process.  Even in the event of catastrophic
> failure, your transactionally serialized changes would still remain in the
> database.  So you could restart and pick up work from where you were last.
>
> You may wish to take a look at the following blog entries:
>
> http://blog.athico.com/2009/03/drools-50-cr1-new-and-noteworthy.html
>
> And the Drools flow documentation.
>
> I'm hoping to move our work in this direction so please do pass on your
> results; unless I'm completely misunderstanding how one can use flow, expert
> and JPA together with transactions.
>
> best wishes,
>
> Andrew
>
> On Sat, Nov 7, 2009 at 9:23 AM, ken.p <ken.annihilation at gmail.com> wrote:
>
>>
>> I am also looking similar feature. We can currently use AOP to send event
>> to
>> stream. However, we have events with relevant duration for days and some
>> time weeks. If server were to restart for maintenance, how do we restore
>> to
>> the same state?
>>
>>
>>
>> Daniel Miller-9 wrote:
>> >
>> > So I hope that someone out here, or many of you, can give me some idea
>> > of how you do this.
>> >
>> > I have about 20+ entities in my database that I want Drools to know
>> > about.  Obviously my hope is to apply CEP, rules and processes to
>> > these items.  However, I feel like I'm missing some type of connection
>> > between how Drools recommends keeping my working memory in sync with
>> > my database changes.
>> >
>> > Ideally, I'd love to be able to just update my entities as I have been
>> > doing in the database, but have those changes automatically move their
>> > way over into the working memory.  How do any of you recommend I
>> > accomplish this?
>> >
>> > Thanks in advance for any suggestions.
>> >
>> > Dan Miller
>> >
>> > _______________________________________________
>> > rules-users mailing list
>> > rules-users at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/rules-users
>> >
>> >
>>
>> --
>> View this message in context:
>> http://old.nabble.com/Maintaining-DB-Working-Memory-Synchronization-tp26238313p26241138.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
>>
>
>
>
> --
> +1 510 342 5693
>
> PO Box 7775 #8750
> San Francisco, California   94120-7775
>
> "Warning:  following standard input indefinitely is ineffective"
> - /bin/tail error message
>
> "Against logic there is no armor like ignorance."
>  - Laurence J. Pete
>



-- 
+1 510 342 5693

PO Box 7775 #8750
San Francisco, California   94120-7775

"Warning:  following standard input indefinitely is ineffective"
- /bin/tail error message

"Against logic there is no armor like ignorance."
 - Laurence J. Pete
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-users/attachments/20091107/21391a9c/attachment.html 


More information about the rules-users mailing list