[infinispan-dev] Hybrid locking scheme in ISPN 5.2.0

Tue May 15 12:23:47 EDT 2012

Btw, if you guys rely on specific LockingInterceptor logic, have you guys tried to take the existing OLI or PLI, and subclassing it to add the stuff that guys rely on?

In theory (I haven't 100% checked this), you can control what the interceptor chain looks like, and you could provide your own implementation, copying or extending/overriding, one of the existing impls.

This might be a good short term strategy given your deadlines.

On May 15, 2012, at 6:20 PM, Galder Zamarreño wrote:

> 
> 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
> 
> 
> _______________________________________________
> 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