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

[Manik Surtani]

Precisely.  Some moron could always set the iso level to NONE and  
then complain about data corruption.

--
Manik Surtani

Lead, JBoss Cache
JBoss, a division of Red Hat

Email: manik at jboss.org
Telephone: +44 7786 702 706
MSN: manik at surtani.org
Yahoo/AIM/Skype: maniksurtani



On 30 Jan 2007, at 08:45, Galder Zamarreno wrote:

> But thinking through it again, not any riskier than the isolation  
> level set in the config.
>
> 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 Galder Zamarreno
> Sent: 30 January 2007 01:07
> To: Brian Stansberry; jbosscache-dev at lists.jboss.org
> Cc: Max Andersen; Steve Ebersole; Bill Decoste; Carlo de Wolf
> Subject: RE: [jbosscache-dev] Problems with node locking  
> semanticsinJBC1.4.1.GA
>
> 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
>
> _______________________________________________
> jbosscache-dev mailing list
> jbosscache-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosscache-dev
>
> _______________________________________________
> jbosscache-dev mailing list
> jbosscache-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosscache-dev