Thank you for the reply. I a not sure where the community effort lives, but would it be
possible send a link in order to take a look?
Ken
On Oct 28, 2010, at 8:28 PM, Kris Verlaenen wrote:
Ken,
In Drools, timers etc. are linked to a session (where the session can
contain process instances, timers, data, rule evaluations, etc.). So,
even if you are using Drools Flow in a clustered environment, where you
could have a number of independent sessions running simultaneously, the
timer will always be associated to that session. There are two possible
strategies then: either (1) you keep the session online for ever (your
cluster has a number of running sessions and you're possibly using
persistence to restore in case of system failure), and the timers will
fire in that session only when the time is right or (2) you only keep
your session alive when it is necessary so sessions can go offline,
where you could then use a scheduler to make sure the session is brought
back online (from persistent storage) whenever a timer should fire in an
offline session. The latter is currently being implemented as a
community contribution.
Kris
Ken Young wrote:
> We are looking at embedding Drools 5.1 (specifically Drools Flow) in our application,
but I am coming up short on determining how to configure clustering, or the support.
>
> Specifically, I want to ensure that background processes that are taking place
(reminders, timers, etc.) only happen once on a cluster. Does drools support this and
how?
>
> In other software that we have clustered (Quartz for example), where a shared
database lock is used to ensure the the processing happens in one place. I was wondering
if Drools 5.1 worked in a similar fashion.
>
> Thanks
> Ken
>
>
> _______________________________________________
> rules-users mailing list
> rules-users(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/rules-users
>