Yes, MaxDB keeps some row locks on SELECTs (these 'row_share' locks you may see in LOCKSTATISTICS) if the isolation level requires it.
Simply speaking, if you want a 'read committed' isolation, you must prevent another session from updating a row if you have accesssed it, cause you might want to read it again (this is an over-simplification). However, how did you produce that selects for the trace files? My colleguages insist that TRANSID is a hex value and can never have a value 'LOB' ... Alexander Schr�der SAP DB, SAP Labs Berlin > -----Original Message----- > From: Andre Reitz [mailto:[EMAIL PROTECTED] > Sent: Monday, February 23, 2004 11:44 AM > To: Schroeder, Alexander > Subject: Re: DEADLOCKS Caused by SELECTS > > > On Mon, 23 Feb 2004 11:29:47 +0100 > "Schroeder, Alexander" <[EMAIL PROTECTED]> wrote: > > > Hello Andre, > > > We have a serious problem with sapdb version 7.4.3.31 (on > SuSE-Linux) > > > - We have clients with long running transactions, all with > > > isolationlevel 1. > > > - Many of them do many SELECTS without commit. > > > - These SELECTS sometimes keep Locks, which block other > > > clients when they > > > trying to write on those tables. > > > > It would be useful going a little into detail here, e.g. > describing what kind are your SELECTs, > > what are the commands that are blocked and hang, and what > is the content of LOCKSTATISTICS at > > that time. > > > > Lockstatistics: (3 different versions) > See attachment. > > > We have around 40 Tables which are linked to each other by > many foreign keys. > The SELECTS use very often joins and outher joins. > > > By the way: > Is it possible that sapdb keeps a row lock when a transaction is only > doing SELECTS in ISOLATIONLEVEL 1? > > > > > > Greetings, Andre' > > > > > > - I was told, that these behaviour was a bug of version 7.3, > > > and that I should upgrade to 7.4. > > > > Those problems made your issues probably only much more > worse, and showed up first. > > > > > - It seems that the problem still exists. > > > > I think the problem has the same symptoms, but is not > necessarily the same ... so please > > send a little more information. > > > > Regards > > Alexander Schr�der > > SAP DB, SAP Labs Berlin > > > > > -- > ______________________________________________________________ > ____________ > > Als Technologieunternehmen konzipieren und entwickeln wir > ma�geschneiderte Feedback- und > Monitoring-Systeme - wie beispielsweise L�sungen f�r > Beschwerde- und Ideenmanagement. > Mit dem Inquery� Survey Server bieten wir eine der > leistungsf�higsten Standardl�sungen f�r > Online-Umfragen mit dem Schwerpunkt auf der Messung von > Kundenzufriedenheit an. > ______________________________________________________________ > ____________ > > > Inworks GmbH > Andre Reitz, Leiter Entwicklung > H�rvelsinger Weg 39, 89081 Ulm, Germany > Tel +49 (0) 731 / 93807-21 > Fax +49(0)731/93807-18 > Internet: http://www.inworks.de > > > -- MaxDB Discussion Mailing List For list archives: http://lists.mysql.com/maxdb To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
