3:40 a.m.
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
3:44 a.m.
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
4:47 a.m.
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
5:17 a.m.
On 30 Mar 2012, at 10:47, Pedro Ruivo wrote:
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?
yes.
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.
so during the
rollback you release the resources (locks, changes) but keep the tx in the tx table as you
know you need to also receive a prepare. When prepare is received the tx would be simply
removed from the tx table without any further work. That should work.
What do you think?
Another issue is where I can implement this behavior? I mean, in TO,
this behavior is implemented in TotalOrderInterceptor a
Do you want to implement TO
for pessimistic transactions? I always thought about total order as only being practical
for optimistic tx.
5:26 a.m.
On 3/30/12 11:17 AM, Mircea Markus wrote:
On 30 Mar 2012, at 10:47, Pedro Ruivo wrote:
> 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?
yes.
> 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.
so during the rollback you release the resources (locks, changes) but keep the tx in the
tx table as you know you need to also receive a prepare. When prepare is received the tx
would be simply removed from the tx table without any further work. That should work.
OK
> What do you think?
>
> Another issue is where I can implement this behavior? I mean, in TO,
> this behavior is implemented in TotalOrderInterceptor a
Do you want to implement TO for pessimistic transactions? I always thought about total
order as only being practical for optimistic tx.
No I don't want pessimistic tx in TO. I was not very clear but I am
worry about the code will be duplicated when TO will be merged (assuming
that you want this solution in your 2PC scheme) :)
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
5:30 a.m.
>> Another issue is where I can implement this behavior? I mean,
in TO,
>> this behavior is implemented in TotalOrderInterceptor a
> Do you want to implement TO for pessimistic transactions? I always thought about
total order as only being practical for optimistic tx.
>
No I don't want pessimistic tx in TO. I was not very clear but I am
worry about the code will be duplicated when TO will be merged (assuming
that you want this solution in your 2PC scheme) :)
We already have this kind of
logic in TOB. You want to avoid duplicating the same code in TOM?
6:03 a.m.
On 3/30/12 11:30 AM, Mircea Markus wrote:
>>> Another issue is where I can implement this behavior? I
mean, in TO,
>>> this behavior is implemented in TotalOrderInterceptor a
>> Do you want to implement TO for pessimistic transactions? I always thought about
total order as only being practical for optimistic tx.
>>
> No I don't want pessimistic tx in TO. I was not very clear but I am
> worry about the code will be duplicated when TO will be merged (assuming
> that you want this solution in your 2PC scheme) :)
We already have this kind of logic in TOB. You want to avoid duplicating the same code in
TOM?
I want to avoid duplicating code between TO and 2PC :)
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
5117
days inactive
5117
days old
infinispan-dev@lists.jboss.org
6 comments
2 participants
participants (2)
-
Mircea Markus -
Pedro Ruivo