[infinispan-dev] Hybrid locking scheme in ISPN 5.2.0

[Galder Zamarreño]

On May 15, 2012, at 10: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;

^ This is still very cryptic, can you be more explicit?

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

The issues with the previous 5.0 locking mechanism have been clearly documented under the hybrid approach in: https://community.jboss.org/docs/DOC-16973

You have not yet given me a single reason why we should put back something that's flawed. All you've said is: i rely on X and I want it back.

If you can explain what exactly you're relying on and for what specific reasons, we might be able to help you further.

Thanks

> 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

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