In 7.4 the implicite row share locks are removed after the record could be copied. In 7.3 this was not built in and so the locks are kept until end of transaction. I recommend you to switch to 7.4. kind regards Uwe
> -----Original Message----- > From: Andre Reitz [mailto:[EMAIL PROTECTED] > Sent: Dienstag, 17. Juni 2003 11:20 > To: Zabach, Elke > Cc: [EMAIL PROTECTED] > Subject: Re: Please Help: Deadlock, Database is blocking > > > On Tue, 17 Jun 2003 10:09:02 +0200 > "Zabach, Elke" <[EMAIL PROTECTED]> wrote: > > > Andre Reitz wrote: > > > > > > > > We have a big problem, > > > > > > We have a client-server Application running on sapdb with > > > a multithreaded python server as a middleware. > > > > > > This means: one Multithreaded program which has several > > > connections on the database (all under the same database user > > > account). > > > > > > > > > Our Problem: > > > > > > - Sometimes the System blocks > > > > > > The possible causes: (we think so) > > > > > > - We forgot a "commit" in our application > > > - Sapdb runs out of free locks or any other resources > > > > > > Our Questions: > > > > > > - Is Isolation Level 1 (or 10) the default of the python driver? > > > - Do selected rows also get locked in Isolation Level 1? > > > > Usually they are not locked. But there exist kernel-versions > > in which a row is selected, but updated by another transaction. > > It then has to wait for the release of that > update/insert/delete-lock, i.e. > > has to wait for the commit/rollback of the other transaction. > > Then it will have a lock afterwards. > > > > Is this a bug or a feature. (We are using sapdb 7.3.0.29) > It sounds like it is a bug, isn`t it? > > > > - If they get locked, is there a limit (maximum of row locks) > > > > > > YES, the installation parameter MAXLOCKS, (default:2500) > > > > > > > which can lead > > > to the blocking because the system runs out of resources > > > (or something similar)? > > > (in other words:) > > > > No, should not block, should return an error > > > > Please check the output of the systemtable LOCKS in > > the case of blocking database. > > > > And please check the value of the parameter > > REQUEST_TIMEOUT. > > > > > > > - Our applications sends many many selects without a > > > following commit/rollback. > > > Only when data is inserted/updated/deleted, the clients > > > send a commit/rollback. > > > Is it possible that the selects will lead to a deadlock? > > > > > > Possible: yes > > > > The same question, bug or feature? > > > > Elke > > SAP Labs Berlin > > > > > > > > - What about the parameter DEADLOCK_DETECTION (my value > currently: 4)? > > > does it use very much resources if i set it to a higher value? > > > does it make sense to set it highter? > > > > > > > > > > > > Thank you very much in advance, > > > Greetings and best regards, Andre' > > > > > > -- > > > _____________________________________________ > > > inworks GmbH Andre Reitz > > > H�rvelsinger Weg 39 Tel. 0731/93 80 7-21 > > > 89081 Ulm http://www.inworks.de > > > > > > _______________________________________________ > > > sapdb.general mailing list > > > [EMAIL PROTECTED] > > > http://listserv.sap.com/mailman/listinfo/sapdb.general > > > > > > > Thank you very much in advance, > > Best regards, Andre' > > > -- > _____________________________________________ > inworks GmbH Andre Reitz > H�rvelsinger Weg 39 Tel. 0731/93 80 7-21 > 89081 Ulm http://www.inworks.de > > _______________________________________________ > sapdb.general mailing list > [EMAIL PROTECTED] > http://listserv.sap.com/mailman/listinfo/sapdb.general > _______________________________________________ sapdb.general mailing list [EMAIL PROTECTED] http://listserv.sap.com/mailman/listinfo/sapdb.general
