Actually, I had a case this morning asking about this. The customer wanted to could
control what the locking type to acquire. I did comment against it due to possible misuse
that could end up in data corruption.
I can see however the possible use cases, but the risks are high as well IMO.
Galder ZamarreƱo
Sr. Software Maintenance Engineer
JBoss, a division of Red Hat
-----Original Message-----
From: jbosscache-dev-bounces(a)lists.jboss.org
[mailto:jbosscache-dev-bounces@lists.jboss.org] On Behalf Of Brian Stansberry
Sent: 29 January 2007 21:49
To: jbosscache-dev(a)lists.jboss.org
Cc: Max Andersen; Carlo de Wolf; Bill Decoste; Steve Ebersole
Subject: FW: [jbosscache-dev] Problems with node locking semantics inJBC1.4.1.GA
Accidentally didn't include the rest of the distribution on this
response.
Brian Stansberry wrote:
I like your thinking on that. Haven't looked at the details, but
the
concept makes a lot of sense.
Was chatting with Manik on this this AM, and here's what we came up
with as an action plan. This is somewhat governed by very tight
release schedules for 1.4.x, along with a desire to not change the
Node interfaces in the 1.x series.
For both Branch_1_4_0 and HEAD:
1) I'll add cache configuration attribute
LockParentForChildInsertRemove. 2) I'll change PLI to use that to
decide whether to acquire a WL or RL. 3) Manik will look into
changing optimistic locking uses that to decide whether
addition/removal of a child causes an increase in the nodes version.
(Not sure if that will be in 1.4.x).
For HEAD only:
4) I'll add a JIRA to make this behavior changeable per node. I'll
open a forum thread for the JIRA and without objection, Elias, I'll
paste your idea as the first post.
- Brian
Elias Ross wrote:
> --- Brian Stansberry <brian.stansberry(a)jboss.com> wrote:
>
>> Even further, that could be treated as a cache wide default, used to
>> set a flag on each node. The PessimisticLockInterceptor could check
>> that flag to decide whether to get the WL. What's nice about that
>> is the cache wide default could be true, but for certain nodes the
>> application could set it to false. E.g the root node for a webapp
>> under which sessions are stored, root node for an SFSB or entity
>> under which instances are stored, PojoCache's _JBossInternal_ node
>> etc. Simpler alternative to lock striping on the child map.
>
> The Node itself keeps a NodeLock instance. Perhaps the specific
> choice of lock (read-write) could be delegated to the NodeLock
> itself?
>
> In particular, for the method:
>
> boolean acquire(Object caller, long timeout, NodeLock.LockType
> lock_type);
>
> it might make sense to replace the LockType parameter with an
> operation parameter? E.g.
>
> boolean acquire(Object caller, long timeout, NodeLock.Operation op);
>
> Then there needs to be some way to set the particular strategy per
> node. It's theoretically possible, but there needs to be a standard
> API to expose this. E.g.
>
> void setLockStrategy( ... );
>
> With this in mind, the NodeLock interface should get revisited in
> time for 2.0.
>
>
>
> ______________________________________________________________
> ______________________ Get your own web address.
> Have a HUGE year through Yahoo! Small Business.
>
http://smallbusiness.yahoo.com/domains/?p=BESTDEAL
_______________________________________________
jbosscache-dev mailing list
jbosscache-dev(a)lists.jboss.org