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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

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.

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(a)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(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

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(a)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(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >> _______________________________________________ >> infinispan-dev mailing list >> infinispan-dev(a)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(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

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(a)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(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >>>> _______________________________________________ >>>> infinispan-dev mailing list >>>> infinispan-dev(a)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(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >> _______________________________________________ >> infinispan-dev mailing list >> infinispan-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/infinispan-dev > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev(a)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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

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(a)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(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >> >> _______________________________________________ >> infinispan-dev mailing list >> infinispan-dev(a)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(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

On 15 May 2012, at 17:10, Galder Zamarreño wrote: > 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. Well, the old scheme was broken and there are several good reasons why we moved to a more consistent approach.

Diego, can't your work be modified to work with the new schemes?

On 15 May 2012, at 17:10, Galder Zamarreño wrote: > 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. Well, the old scheme was broken and there are several good reasons why we moved to a more consistent approach. Diego, can't your work be modified to work with the new schemes?