Renner Klaus wrote: > We have a big deadlock-problem, > > Kernel 7.4.3 Build 017-123-039-277 > Runtime Environment : X64/SUN 7.4.3 Build 017-123-039-277 > > A java-program fills our sapdb with data running on localhost every 5 > minutes. This is done in one transaction. The required time > normally varies > from 20 seconds to some minutes. > So we stored about 6 Gigabytes in a few tables, all belonging > to the same > database user account. > > To read this stuff we are using a java-servlet with jdbc on > tomcat on a > remote computer. This program uses only select, no insert or update . > When using the query-program in the timespan while the > data-feed program is > inserting data, then the deadlock occures. > Closing the webinterface has no effect, tomcat still holds > the connections. > Stopping the application in tomcat causes tomcat to release > connections > after 20 minutes. So the concurrent tasks should be finished, > but after > closed connections the feed-program is still waiting further > 10 minutes > before finishing with some (ca 1000) insert-statements. > > Table LOCKSTATISTICS shows "?" for REQMODE and ROWIDHEX > > KNLDIAGERR has no entry since last startup > > KNLDIAG shows a few warnings like this: > 2003-10-14 17:23:23 128 WNG 11824 COMMUNIC Releasing T120 > command timeout
Which isolation level is used by the java-servlet? With iso levels TRANSACTION_READ_UNCOMMITTED and TRANSACTION_READ_COMMITTED there should be no locks forced by pure select commands without for update clause. So if you already use one of these two iso levels and no select for update command we would be interested in the output of the select * from lockstatistics at the deadlock time. Best regards, Holger SAP Labs Berlin -- MaxDB Discussion Mailing List For list archives: http://lists.mysql.com/maxdb To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
