Re: [infinispan-dev] Undesired behavior
With the optimistic locking scheme, I think I can use the same approach.
The locks are only acquired in the prepare phase, so I can discard the
prepare message, right?
But if the pessimist locking scheme is in use?
One possible solution is, If rollback is delivered first, the
TxInterceptor skips the write commands replays and in
PessimistLockingInterceptor, invoke the lock.unlockAll(ctx) method.
What do you think?
Another issue is where I can implement this behavior? I mean, in TO,
this behavior is implemented in TotalOrderInterceptor and TotalOrderManager.
Any though?
Cheers,
Pedro
On 3/30/12 9:44 AM, Mircea Markus wrote:
can't use the same approach as you do with total order broadcast
in which you mark the tx for rollback only during rollback and when the prepare is
received you just cleanup things?
On 30 Mar 2012, at 09:40, Pedro Ruivo wrote:
> Hi everybody,
>
> The problem is the following: I have some cases where the
> RollbackCommand is processed before the correspondent PrepareCommand,
> leading to locks to be acquired and never unlocked again.
>
> I am in a scenario where the dataset of each node is disjoint (no
> contention) but I have large transactions. When a transaction aborts, I
> execute it again (so it has the same keys modified) and try to commit
> it. Initially, the transaction aborts due to timeout waiting responses
> (that is 2 min and 30 sec), but after, I see aborts due to lock
> acquisition timeout. The final result is that all the nodes in the
> system finishes except this one.
>
> Is there anyway to release the locks for previously finished transactions?
>
> Cheers,
> Pedro Ruivo
> _______________________________________________
> 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