[infinispan-dev] Keeping track of locked nodes

Dan Berindei dan.berindei at gmail.com
Fri Jan 20 04:11:59 EST 2012


In this particular case it just means that the commit is sync even if
it's configured to be async.

But there are more places where we check the remote lock nodes list,
e.g. BaseRpcInterceptor.shouldInvokeRemotely or
AbstractEnlistmentAdapter - which, incidentally, could probably settle
with a "hasRemoteLocks" boolean flag instead of the nodes collection.

TransactionXaAdapter.forgetSuccessfullyCompletedTransaction does use
it properly when recovery is enabled - if we didn't keep the
collection around it would have to compute it again from the list of
keys.

The same with PessimisticLockingInterceptor.releaseLocksOnFailureBeforePrepare,
but there we're on thefailure path already so recomputing the address
set wouldn't hurt that much.

I may have missed others...

Cheers
Dan


On Fri, Jan 20, 2012 at 8:52 AM, Manik Surtani <manik at jboss.org> wrote:
> Well, a view change may not mean that the nodes prepared on have changed.  But still, there would almost certainly be a better way to do this than a collection of addresses.  So the goal is to determine whether the set of nodes the prepare has been sent to and the current set of affected nodes at the time of commit has changed?  And what are the consequences of getting this (pessimistically) wrong, just that the prepare gets repeated on some nodes?
>
>
> On 20 Jan 2012, at 03:54, Mircea Markus wrote:
>
>> On 19 Jan 2012, at 19:22, Sanne Grinovero wrote:
>>> I just noticed that org.infinispan.transaction.LocalTransaction is
>>> keeping track of Addresses on which locks where acquired.
>>> That's surprising me .. why should it ever be interested in the
>>> specific Address? I'd expect it to be able to figure that out when
>>> needed, especially since the Address owning the lock might change over
>>> time I don't understand to track for a specific node.
>> This information is required at least here[1], but not sure wether we cannot rely on the viewId which is now associated with every transaction to replace that logic.
>> [1] http://bit.ly/wgMIHH
>>
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> --
> Manik Surtani
> manik at jboss.org
> twitter.com/maniksurtani
>
> Lead, Infinispan
> http://www.infinispan.org
>
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev



More information about the infinispan-dev mailing list