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

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&gt; 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