Hello, I think you run into a known bug in the database kernel which only occurs in conjunction which JDBC.
A call of the method Statement.close() closes the cursor and generates a "Close Cursor <cursor name>"-command. At the same time the application closes the corresponding connection. Then the jdbc driver will send a combined "commit work release" and "close cursor <cursorname>"-order in one chunk to the database kernel. If the kernel process closing the cursor after closing the connection a memory leak inside the database kernel will occur. And this is also the reason for the space consumption in tempspace that you have reported. The newest available JDBC-driver at: ftp://ftp.sap.com/pub/sapdb/bin/java/sapdbc.jar contains a workaround for this kernel bug. The kernel team has also fixed this bug in the kernel 7.3.0.32 / 7.4.3.11. I've tested your sample code with the newest JDBC-driver and the temp space consumption is constant. So I think using the newest JDBC-driver should solve your problem. Regards, Marco ---------------------------------------------- Marco PASKAMP SAP DB, SAP Labs Berlin > -----Original Message----- > From: Steven Dolg [mailto:[EMAIL PROTECTED]] > Sent: Donnerstag, 16. Januar 2003 17:32 > To: [EMAIL PROTECTED] > Subject: WG: persitent locks and data space consumption > > > Hello again, > > I managed to find out what caused the problem with the data > space consumption described below. (the remaining locks seems > to be something else...) > I wrote a simple test program. Here the main part of it: > > Class.forName("com.sap.dbtech.jdbc.DriverSapDB"); > > for (int i=0; i<50; i++) > { > System.out.println("cycle " + (i + 1) + " "); > lo_Connection = > DriverManager.getConnection("jdbc:sapdb://localhost/mydb", > "user", "pwd"); > lo_Statement = > lo_Connection.prepareStatement("select * from mytable"); > lo_ResultSet = lo_Statement.executeQuery(); > > while (lo_ResultSet.next()) > { > } > > lo_ResultSet.close(); > lo_Statement.close(); > lo_Connection.close(); > > Thread.sleep(50); > } > > When I run this program every loop increases the amount of > temporary data space needed by my database by 8 KB. So after > finishing the program the used temporary data space was > increased by 400 KB. > > Somehow I found out that this can be avoided when I do not > close the statement. > So changing the last block > > lo_ResultSet.close(); > lo_Statement.close(); > lo_Connection.close(); > > to: > > lo_ResultSet.close(); > //lo_Statement.close(); > lo_Connection.close(); > > fixes the problem. > > This seems to be a problem in the JDBC driver. > I'd be very happy if someone who had similar problems or > knows about this one could drop me a line. > > Right now the JDBC driver is a vital part of the project I'm > currently working on. So a fix or another version of the > driver is very important. > Since I already know, where the problem occurs I'd be willing > to fix it myself but in that case I think I need some help > from a developer of SAPDB. > > I'd be very glad if someone answers... > > > with kind regards, > Steven Dolg > > > -----Urspr�ngliche Nachricht----- > Von: Steven Dolg > Gesendet: Mittwoch, 15. Januar 2003 17:09 > An: '[EMAIL PROTECTED]' > Betreff: persitent locks and data space consumption > > Hello, > > I'm having difficulties using SAPDB 7.3.0.29 on Win2000. > Using a Java application (with the latest JDBC driver) > I write into the database updating a row (I receive signs of > life from another machine and store the time of arrival in > the database) > > Using the Database Manager 7.4.2.6 I watched the number > of locks on the database (instance -> information -> locks). > The thing that confuses me is that the number of locks > (both row and table locks) only increases. It really never > decreases even if I shut down my application. > Referring to the manual this is the number of currently > held locks. It is possible that there are more than 10.000 > table locks in a database containing about 30 tables? (The > request timeout is 30 seconds). > > There is another problem which I think is related to > this: (still the same application mentioned above) > In some special occasions the remote machine does not > send a sign of life but an alert. In this case there a some > actions needed to be taken. > This causes the application to perform a number of > additional database operations (like storing the alert message...) > For tests I created an alert every 2 seconds (which > resulted in an increased but not extrem load). > > After about 100 alerts the available space for data > started to shrink extrem fast. Of course rows were inserted > but the space was consumed much faster than anticipated. > Finally the data space usage reached 50 % (starting at 13 % > of 100 MB). At this point no more operations on the database > were possible. > After restarting the database (online -> offline -> > online) the data space usage was back about the value before > my test (there was a negligible increase due to the added data). > > The same application already completed test runs with > more than 15.000 alerts when using MySql oder MS SQL-Server. > A similar situation never occured there. > > > I'd be grateful for any help I could get (since I'm > quite new to SAPDB). > > i. A. Steven Dolg > Software Developer > _____________________________ > Silverstroke AG > Ludwig-Erhard-Stra�e 2 > D-76275 Ettlingen > > Phone +49 (0) 7243 / 346-12 23 > Fax +49 (0) 7243 / 346-12 79 > <mailto:[EMAIL PROTECTED]> > <http://www.silverstroke.com> > _____________________________ > This mail and any files transmitted with it is intended > to be confidential and for the use of only the individual or > entity named above. > If the reader of this message is not the intended > recipient, you are notified that retention, dissemination, > distribution or copying of > this mail and files transmitted with it is strictly > prohibited. If you receive this mail in error, please notify > us immediately by mail or > phone and delete the mail and any files transmitted > with it. Thank you! We also like to inform you that > communication via mail over > the internet is insecure, and third parties may have > the possibility to access or manipulate the mail and any > files transmitted with it. > > > > _______________________________________________ > 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
