[infinispan-dev] Keeping track of locked nodes

[Sanne Grinovero]

On 20 January 2012 11:49, Mircea Markus <mircea.markus at jboss.com> wrote:
>
> 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.

Just to clarify, I wasn't reporting a contention point or a
performance issue. I was just puzzled by the design as it's very
different than what I was expecting. I think we should move towards a
design for which we don't really consider the locks to be positioned
on a specific node, they should be free to move around (still
deterministically, I mean on rehash).
Not asking for urgent changes!

Cheers,
Sanne