Re: [infinispan-dev] Keeping track of locked nodes
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(a)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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Manik Surtani
manik(a)jboss.org
twitter.com/maniksurtani
Lead, Infinispan
http://www.infinispan.org
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev