[rules-dev] BRMS: Locking

Wed Nov 28 23:09:42 EST 2007

HI Darko. Yes I think the error is getting mis-reported, as it checks for
the optimistic lock - I will change it to give a nicer message (and also
tell you who did made the change !).

Yeah - as for locking, in my experience, you either need to have optimistic
locking all the way, or you have "lock and edit" as a feature, which people
have to be aware of (and tools to unlock things by force). Anything in
between will not really work, as you point out, you can't really guarantee
you will know when the user intends to unlock, or is finished, or is editing
(well at the very least you will need tools to manage the locks).

I guess some other ideas are to warn people if we know someone else has
opened it (not sure how well that would work in practice), or, have an
option for people to place and remove locks on assets (and so it shows up
clearly that "XYZ" person has locked something - presumably as they are
working on it).

Hope that clears things up (have been fairly busy lately, and at a
conference, so not frequently getting into mail !).

Michael

On Nov 23, 2007 1:47 AM, Darko IVANCAN <ivancan at gmx.de> wrote:

> 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 at gmx.de
> > <mailto:ivancan at 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 at lists.jboss.org <mailto:rules-dev at 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 at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/rules-dev
> >
> _______________________________________________
> rules-dev mailing list
> rules-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
>

-- 
Michael D Neale
home: www.michaelneale.net
blog: michaelneale.blogspot.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-dev/attachments/20071129/1e533cd5/attachment.html 