Monday, January 30, 2006, 7:46:42 PM, Craig L Russell wrote: > Hi,
> On Jan 27, 2006, at 4:11 PM, Ramandeep Kaur wrote: >> Hi, >> >> As per Stan's mail about prepared statements, I checked the source >> code for DOTS test case that John ran (ATCJ2.java) to see if >> prepared statements are getting closed properly. I found that there >> are few methods in ATCJ2.java where prepared statements are not >> getting closed. >> >> In addition, in doBid() method, >> pstmt.close(); and pstmt = null; should be added right after the >> following block. >> >> pstmt = conn.prepareStatement(updateBidItemSQL + "'" + itemID + "'"); > Any reason why itemID is bound to the preparedStatement and not > itself passed as a parameter? > Generally, preparing statements like this (those that include > parameters) just before use has little benefit. The big win is to > prepare the statement and then reuse it everywhere. So if you change > the updateBidItemSQL to include the itemID as a ? parameter, then > pstmt.setInt(3, itemID) you will get the benefit of prepared statements. > Craig I am fully aware of this rather strange and inefficient use of PreparedStatements in the DOTS test case. As I stated in my first E-mail in this thread: "I don't know the rationale behind doing it this way. It may be just "sloppy code", or it may be intentional." I guess we have to ask the creators of DOTS for the answer. I have not made any inquiries in this regard as of this time. However, DOTS is a part of the Open Source project called "The Linux Test Project", which is "a joint project started by SGI and maintained by IBM®" ( http://ltp.sourceforge.net/ ), so I guess nothing stops us from doing so... However, my main concern right now is that Derby is not robust enough to handle code of this type without running out of memory within a relatively short period of time. I guess that since (even) the DOTS creators wrote such code, other Derby users may be inclined to do so in the future. I would (with help from the Derby community) like to get this issue into the open and (if it is agreed that it is a Derby issue) resolved, and I intend to provide as much information as I can in this regard. Having said that, I would like to point out that Derby is obviously not the only DB with such problems, see Q4 under "Q&A" in the DOTS User's Guide: http://ltp.sourceforge.net/dotshowto.php#SEC42 -- John
