Hi Olivier, This is the request log from the scenario I described in my previous email:
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. Request Log: --------------- 11:44:04,908 abrazo B 2 11:44:04,913 abrazo W 6 2 insert into table1 values (10)/ 11:44:15,917 abrazo B 3 11:44:15,924 abrazo W 7 3 insert into table1 values (20)/ 11:44:16,841 abrazo W 8 3 update table2 set field1 = 1 where field1 = 1/ 11:44:23,289 abrazo W 9 2 update table2 set field1 = 1 where field1 = 1/ 11:44:26,249 abrazo W 10 3 insert into table1 values (22)/ 11:44:55,499 abrazo R 2 2006-09-29 11:47:46,133 DEBUG controller.RequestManager.abrazo Commit transaction 3 11:47:46,132 abrazo C 3 My expectations are that this scenario should lead us to any deadlock. It is only one table that should be locked (but not deadlock) and that is table2 during an update on the same record. Once the first transaction that updated this table is committed then the second transaction should be able to be committed with no issues. Even more I don't understand why the deadlock occurs when on an insert statement (that in a scenario without the update statement works just fine)... Thanks a lot, Ioana --- Olivier Fambon <[EMAIL PROTECTED]> wrote: > Julio Leyva wrote [09/29/2006 03:11 PM]: > > > > Actually these are the messages when we ran the > test with 2 backends > > (postgresql 8.14) > ... > > > So The messages in the previous e-mail is when we > ran the test just > > with one backend > > > > The test still run, but is extremly slow with > sequoia, I believe because > > of the deadlock, however when we run the > aplication without sequoia > > there is no deadlock reported by postgresql. > > The traces you get with your 2 backends/raidb1 > config are "normal": > sequoia detects a deadlock condition in your > application, chooses a > victim, and notifies with ERROR and WARN messages. > > Sequoia enforces a slightly stronger locking that > postgresql in order to > guarantee consitency on backends. This extra > consitency constraint can > cause 'artificial' deadlock conditions which would > not happen when > running directly against the db. > > > > 2006-09-28 14:25:00,805 WARN > backend.DatabaseBackend.testdb1 No > > transaction medatada found for transaction > 13952628 releasing locks > > manually > > 2006-09-28 14:25:00,807 WARN > backend.DatabaseBackend.testdb2 No > > transaction medatada found for transaction > 13952628 releasing > > > These two look strange however... but I have no clue > as to why it is > related to your problem. > > A+O. > > _______________________________________________ > Sequoia mailing list > [EMAIL PROTECTED] > https://forge.continuent.org/mailman/listinfo/sequoia > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com _______________________________________________ Sequoia mailing list [EMAIL PROTECTED] https://forge.continuent.org/mailman/listinfo/sequoia
