[infinispan-dev] Hybrid locking scheme in ISPN 5.2.0

Galder Zamarreño galder at redhat.com
Tue May 15 12:20:48 EDT 2012


On May 15, 2012, at 4:58 PM, Paolo Romano wrote:

> Hi Galder,
> 
> Let me try to clarify this.
> With Diego we have developed a system for 
> forecasting the performance (e.g. maximum throughput, abort rate, avg. 
> transaction execution time) of an ISPN application when it is deployed 
> on a cluster of a different scale (compared to the current one).
> 
> We modelled using analytical techniques and machine learning the locking 
> and network-related behaviors of ISPN, but we did our work on ISPN 5.0 
> (replication mode), which used this "hybrid", partially local/partially 
> remote (and distributed=> no primary owner).
> 
> In other words, our performance prediction schemes won't work neither 
> for Optimistic nor for Pessimistic.

Why do the predictions don't work? 

Where you guys somehow overriding some of the existing logic in 5.0 to track or record some data?

> That's why we were hoping there was 
> a way to revive that locking strategy on 5.2.

We have not even done a single 5.2 release yet btw.

> BTW, we're trying to see how much time it would take us to build a new 
> performance forecasting model capturing the 5.2 dynamics.... wish us 
> good luck because we will need it ready in 15 days….
> 
> Cheers,
> 
>     Paolo
> 
> 
> On 5/15/12 9:57 AM, Diego Didona wrote:
>> Hello again,
>>     I need this behaviour because I have a piece of software which
>> relies on the knowledge of ISPN's locking scheme and it is *explicitly*
>> tailored for the locking scheme of ISPN 5.0; now I have to move to ISPN
>> 5.2 so I just wanted to know if there is any chance of having my
>> previous software working with 5.2.
>> Thanks.
>> 
>> Regards,
>>     Diego
>>> On May 14, 2012, at 5:53 PM, Diego Didona wrote:
>>> 
>>>> Thanks Galder,
>>>>    I am reading again the documentation you linked and I am also running
>>>> some simple tests but I see this behaviour:
>>>> -  with OPTIMISTIC mode the lock is acquired *only* at prepare time
>>>> (thus *not* like in ISPN 5.0);
>>>> -  with PESSIMISTIC mode the lock is acquired at encounter time on the
>>>> primary node (again, thus *not* like in ISPN 5.0).
>>>> 
>>>> The behaviour I'm looking for is        only-local encounter-time
>>>> locking + cluster-wide prepare-time locking.
>>> I can see what you mean by differences now, but why do you need this behaivour?
>>> 
>>> What is your use case? IOW, what is the problem that you're having that requires you to get local locks first?
>>> 
>>>> Am I missing something?
>>>> Thanks again. Regards,
>>>>     Diego
>>>>> That's already possible, seehttps://docs.jboss.org/author/x/FAY5
>>>>> 
>>>>> Btw, the community wikis, like the one pointed below, are now used as design documents. For the user guide, head tohttps://docs.jboss.org/author/display/ISPN.
>>>>> 
>>>>> Cheers,
>>>>> 
>>>>> On May 4, 2012, at 5:08 PM, Diego Didona wrote:
>>>>> 
>>>>>> Hello,
>>>>>>     looking at the code of ISPN 5.2 (and 5.1) I have seen that the
>>>>>> LockingIntercetor has been replaced with new ones. I would like to know
>>>>>> if there is the possibility to have ISPN 5.2 (or 5.1) working with the
>>>>>> *same* hybrid locking scheme described in [1], which was the default
>>>>>> till ISPN 5.0 and entailed the encounter-time write-locks acquisition
>>>>>> during the "local" execution of a transaction and then their remote
>>>>>> acquisition on other nodes at prepare time.
>>>>>> Of course I would like to know if this is feasible just by tweaking some
>>>>>> configuration parameters, without having to modify the source code.
>>>>>> Thanks,
>>>>>>     Diego
>>>>>> ------------------------
>>>>>> [1]https://community.jboss.org/wiki/OptimisticLockingInInfinispan
>>>>>> _______________________________________________
>>>>>> infinispan-dev mailing list
>>>>>> infinispan-dev at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>>> --
>>>>> Galder Zamarreño
>>>>> Sr. Software Engineer
>>>>> Infinispan, JBoss Cache
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> infinispan-dev mailing list
>>>>> infinispan-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>> _______________________________________________
>>>> infinispan-dev mailing list
>>>> infinispan-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>> --
>>> Galder Zamarreño
>>> Sr. Software Engineer
>>> Infinispan, JBoss Cache
>>> 
>>> 
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> infinispan-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> 
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache




More information about the infinispan-dev mailing list