Andre Reitz wrote: > We have an application with several connections to the same > database (under the same user) > > Database: > - 7.3.0.29 Linux i386 > > Our Problem: > - Sometimes 2 or more clients lock each other > - All connections are openen in Isolation Level "Read Committed" > > Please tell me if I am right: > > - Many many selects in Isolation Level "Read Committed" from > several connections do not permanently lock (sharelocks) > Rows. They lock the rows only during the execution of the selects > > - After a select is executed, no rows will remain locked, > even if I do not commit / rollback. > > - The only cause for a blocking connection in Isolationlevel > "Read Committed" can be: > Devspace is Full > Log is Full > A Manipulation (Insert / Update / Delete) or explicit Lock > (Lock table ....) is not committed or rollbacked. > > - Is it possible that a typical deadlock can happen? > (Client 1 waits for Client 2 to commit/rollback and Client > 2 waits for Client 1 to commit/rollback) > >
In some cases the check for uncommited rows could result in locks which stays til the end of the transaction. With this bugfix http://www.sapdb.org/webpts?wptsdetail=yes&ErrorType=1&ErrorID=1118826 it should be solved in 7.4 releases. Unfortunately I couldn't find any thing about 7.3, so perhaps this bug still exists in 7.3 I will check this with the guy who is responsible for the lock topic. Although without this bug a deadlock is possible. But simple deadlocks like this t1 updates row1 t2 updates row2 t1 selects row2 -> wait for commit of t2 t2 selects row1 -> wait for commit of t1 should be resolved by the deadlock detection within SAP DB. You could try to analyze your lock situations with the system table lockstatistics. Best regards, Holger SAP Labs Berlin _______________________________________________ sapdb.general mailing list [EMAIL PROTECTED] http://listserv.sap.com/mailman/listinfo/sapdb.general
