3:47 p.m.
Hi Michael,
Nice to have such a quick feedback.
"What do I mean?" Indeed I am looking at the clustered solution, but ...
first things first. So I am looking at the "single BRMS" server solution
first.
Currently, when a conflict appears I get an error, which sounds more
serious than: "Somebody else already updated that rule, please update
and modify the latest version."
So having a single BRMS server:
(Case 1)
"Simple rule" (i.e. one edited in the BRMS editor)
a) as soon as somebody opens a rule, he is viewing it - no locking required.
b) as soon as somebody edits a rule - the rule should get locked, so no
other users can edit it (but view, in its old state).
c) when the edit is finished, and the changes saved, the user sees it's
changed rules, so no lock is needed, thus the lock is released.
(Case 2)
"Off-line editing rule" (i.e. Excel sheet)
a) When somebody downloads an Excel sheet, it means he's viewing it,
thus no locking would be required
b) When somebody started editing that sheet, the BRMS is oblivious to
that, the user should set a lock.
c) When the user uploads the new version he should release the lock.
So far the theory: Here now some more questions:
A) How to handle, if the user needs to lock a rule, but will not modify
it right away ?
Allow the user an explicit lock/unlock sounds like a good way to go.
B) How to handle, if the user needs to lock a rule, but has to log out
between the start and the end of the modification ?
As in (A), as he can save, log out and log in and then unlock.
C) What happens is the user takes a lock and ...does not unlock it ?
An unlock for others than the users should be allowed to a certain Role
(Admin, LockAdmin, ...).
If we want to have that in a cluster, than obviously the lock should be
propagated.
I don't know if this is supported by JackRabbit.
And I do not see a real need for that, as I have never seen any rule
project with so many rule editors, that this would be needed, except for
the initial set of rules. Afterwards a Role-Package assignment always
helped.
Thanks a lot so far,
Darko Ivancan
P.S.: I'll have a look at the code to see what I can do.
On 22/11/2007 14:03, Michael Neale wrote:
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(a)gmx.de
<mailto: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(a)lists.jboss.org <mailto:rules-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/rules-dev
<https://lists.jboss.org/mailman/listinfo/rules-dev>
--
Michael D Neale
home: www.michaelneale.net <http://www.michaelneale.net>
blog: michaelneale.blogspot.com <http://michaelneale.blogspot.com>
------------------------------------------------------------------------
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev