Hi Ioana,
Scenario:
----------
Client 1 - Insert Into Table1
Client 2 - Insert Into Table1
Client 2 - Update Table2
Client 1 - Update Table2 - this is the same record
updated by Client 2 - Update Table2 - so it is gonna
be locked until the transaction for Client 2 is
committed
Client 2 - Insert Into Table 1 - This is where the
problem starts because this is locked by Client 1 and
it shouldn't be. It is an insert on a new record.
Unfortunately, the scenario you describe will be detected as a deadlock
by Sequoia at the table level (client 1 locks t1 then t2 and client 2
locks t2 then t1). Even if row level locking allows you to not see that
deadlock when using directly PostgreSQL (not that this may not be always
true), Sequoia cannot ensure 1-copy serializability if we do not detect
a deadlock here.
A solution to your problem is to set the 'enforceTableLocking' option to
true in the WaitForCompletion element of your load balancer definition.
This will serialize the order of lock acquirements and will prevent the
deadlock scenario you are describing.
Hope this helps,
Emmanuel
--
Emmanuel Cecchet
Chief Architect, Continuent
Blog: http://emanux.blogspot.com/
Open source: http://www.continuent.org
Corporate: http://www.continuent.com
Skype: emmanuel_cecchet
Cell: +33 687 342 685
_______________________________________________
Sequoia mailing list
[email protected]
https://forge.continuent.org/mailman/listinfo/sequoia
