On 20 Jan 2012, at 09:33, Manik Surtani wrote: > > On 20 Jan 2012, at 14:41, Dan Berindei wrote: > >> 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… > > Cool. Mircea, reckon we can patch this quickly and with low risk? Or is it > high risk at this stage? I don't think it's a good moment for this right now. I'm not even convinced that this is the way go, as it might be cheaper to cache this information than to calculate it when needed.
_______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
