db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From edson.rich...@mgrinformatica.com.br
Subject Re: OutOfMemoryErrors when testing Derby with DOTS
Date Tue, 31 Jan 2006 20:59:09 GMT
> Craig L Russell wrote:
>> Long term, I don't believe that Derby or any other implementation
>> should try to optimize for applications written without regard for  good
>> programming patterns.
> In this case Derby needs to follow the JDBC spec and correctly handle
> garbage collected JDBC objects. I don't think anyone is optimising Derby
> here, just ensure it behaves correctly. Derby should not fall over
> because of a badly written application, that will not encourage people
> to use Derby. Fact of life is that people write bad JDBC applications,
> Derby needs to handle those.

I must disagree. Every great database player say "close your results/statements", because
there is no way for an database know if a cursor is still needed, and you cold lead to a
server crash or messages like "there is no more cursors avaliable". Any developer who read
database docs about Java programming will read recomendations about bellow pattern.

The correct (and hard-to-crash) piece of code is:

long someMethod(Connection conn, ...)
  throws MyCustomException
   PreparedStatement ps = null;
   ResultSet rs = null;
   long result;

   try {
      ps = conn.prepareStatement(MY_SQL);
      ps.setInt(1, ...);
      ps.setInt(1, ...);
      rs = ps.executeQuery();
      // use rs to calulate result
   } catch(Exception e) {
      throw new MyCustomException(e, "error doing something");
   } finally {
      if(rs !=null) {
         try {
`           rs.close();
         } catch(Exception exc) { // oh, God, there is nothing I can do here! }
      if(ps!=null) {
         try {
`           ps.close();
         } catch(Exception exc) { // oh, God, there is nothing I can do here! }

   return result;

(if there is some sintax error, sorry - I typed this in mail program directly)

I have used this piece of code for years, and never got any memory or cursor problems with
MaxDB, MS SQL, Oracle, Sybase SQL, MySQL, PostgreSQL, Access, Interbase, or Derby!!!

> There's no guessing, if the application has a reference to an open JDBC
> object then it is still using it. If it no longer has a reference to a
> open JDBC open then it is no longer using it and Derby must garbage
> collect it.

Well, this could happend on a perfect world. I didn't find any GC that works fine. And what
a Garbage Collection will know about cursors avaliability? I think if you have a GC that is
able to collect resultsets, how could he inform a remote server that a cursor is not needed
any more? During garbage a ResultSet will need to inform the server it's no more open? How
could a object know it's being collected? There is some kind of event we can listen?

So, if you can't inform remote server (and AFAIK, it's not possible), you will save client
from OOM exceptions, but still can crash server (or run out of cursors, so common in Oracle
servers with badly designed apps).

I'm sure there is a good connection pools capable of closing everything for you after some
time of inactivity - so your badly desined web app will not suffer this problem. BUT, then
you must use this connection pool software to make your tests too.



View raw message