[jbosscache-dev] Problems with node locking semantics inJBC1.4.1.GA

[Galder Zamarreno]

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 at lists.jboss.org [mailto:jbosscache-dev-bounces at lists.jboss.org] On Behalf Of Brian Stansberry
Sent: 29 January 2007 21:49
To: jbosscache-dev at 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 at 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 at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosscache-dev