hi Darko.

No that is optimistic locking. When they are opened there is no lock or anything. The second one failed cause it was stale data.

To do more aggressive locking would be trickier (as they you have to have a means to unlock things). There could be a more active type thing that warns people someone has something open (but of course its stateless, so its only "best guess"). This is like 99.9% of other apps out there, you have to make a decision on how to treat this locking scenario. Would be interested to discuss more about it though, as it is something that you are interested in.

This is all talking about a single BRMS server, with muliple clients.

If you mean multiple BRMS instances, then more work needs to be done to configure jackrabbit to share indexes etc. Is that what you mean?

Michael.

On Nov 22, 2007 10:15 PM, Darko IVANCAN < ivancan@gmx.de> wrote:
JBoss AS 4.0.5
JBoss Drools 4.0.3
JDK 1.5.13

Hi,

I'm evaluating JBoss Drools and wanted to check the locking capabilities
in the BRMS, to see it the BRMS can be used on a cluster, i.e. multiple
BRMSs one DB-Server.

So I started first on one single machine, just to check the locking
capabilities:
Started BRMS, logged in using FireFox and Logged in using Safari.
1) Open one (and the same) rule in both session
2) edit and save rule in one session
3) edit and save rule in another session
=> error

So, from what I see there is no locking mechanism in the BRMS.
As from what I see in JackRabbit, it does support transactions, but
locking seems to be needed in the BRMS itself, i.e. one layer above
JackRabbit.

My question, and maybe someone can answer/confirm these spending some of
his valuable minutes:
1) Is locking included or on the roadmap ?
2) Did I miss a configuration parameter to enable locking ?
3) How can stale-locks be cleaned ? Admin-only?

Thanks a lot for your valuable input and thanks for this great product,
Darko Ivancan
_______________________________________________
rules-dev mailing list
rules-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev



--
Michael D Neale
home: www.michaelneale.net
blog: michaelneale.blogspot.com