db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel John Debrunner <...@debrunners.com>
Subject Re: SQLExceptions and OutOfMemoryExceptions
Date Tue, 22 Nov 2005 20:48:31 GMT
Lance J. Andersen wrote:

> Daniel John Debrunner wrote:
> 
>> Somewhere in the JDBC specs/api/tutorial it says that JDBC drivers
>> should throw SQLExceptions rather than generic exceptions. Thus a
>> SQLException is preferred to a NullPointerException.
>> [I can't find that text now, though :-(]
>>  
>>
> That is correct where possible a SQLException is the correct error.  You
> can set it cause, starting in JDBC 4 to the real culprit.
> 
>> For out of memory exceptions, this causes somewhat of a problem. I have
>> code that fails gracefully if an OutOfMemoryException is thrown during
>> establishment of a connection. The issue is that trying to create the
>> new SQLException will fail due to an OutOfMemoryException. :-(
>>  
>>
> Not sure you want to jump through hoops for an OutOfMemoryException, i
> do not think it is worth it.

But I do :-). We are seeing several cases where users of Derby are
seeing OutOfMemoryExceptions, not because of memory leaks, just because
Derby is allocating too much memory. An easy to use database would
recover gracefully from this, and allow continued operation as best as
possible.

http://issues.apache.org/jira/browse/DERBY-443

>> One work-around is to pre-allocate a static singleton SQLException for
>> this out of memory case, there are two problems with this:
>>
>> - The original OutOfMemoryException cannot be chained to the singleton,
>> thus some useful information is lost (the original stack trace).
>>
>> - Looking forward, there would need to be several (many?) singleton
>> SQLExceptions, for example the one I'm experimenting with has a SQLState
>> starting with 08 indicating a connection failure. E.g. an
>> OutOfMemoryException during an executeQuery would need a SQLException
>> with a different SQLState.
>>
>> The other alternative is to directly throw the OutOfMemoryException as
>> this requires no new object allocation. The problem with this is that it
>> is less natural for applications, which will be catching SQLException
>> but most likely not OutOfMemoryExceptions. And it removes the
>> possibility of using the JDBC SQLException sub-classing to indicate that
>> the operation is re-tryable.
>>
>> Maybe there's also the option of trying to allocate a new SQLException
>> and if that fails revert to using the singleton, or throwing the
>> original OutOfMemoryException.
>>  
>>
> If you are out of memory, will there ever be a chance to create a new
> SQLException object?

Yes, the process of throwing an exception can catching it further up the
stack will allow objects to be garbage collected that were only
referened from local variables. A simple example,

    byte[] A1= new byte[10000];

    byte[] A2= new byte[30000];

If the OutOfMemoryException is thrown allocating A2, and caught further
up the stack (as happens with the JDBC driver], then the memory for A1
can be collected.

Or even simpler, if I try to allocate 1Mb and fail, there is probably
still enough memory to allocate a SQLException.

Thanks,
Dan.


Mime
View raw message