Bryan Pendleton (JIRA) wrote:
[ http://issues.apache.org/jira/browse/DERBY-1497?page=comments#action_12420324 ]
Bryan Pendleton commented on DERBY-1497:
----------------------------------------
It seems like it would be nice if we printed the original exception's stack
trace
somewhere prior to discarding it.
Otherwise, when this happens, all we'll know is that we ran out of memory, but
we
will lose some potentially useful information about exactly which line of code
we
were on when we ran out of memory.
Unless the streaming could be fixed so that we avoid outofmemoryerrors
on the receiver side, I would propose the following:
We know the size of the LOB, and can check if it can go into memory
(using the Runtime class). If it cannot go into memory, we can throw an
SQLException, instead of consuming all memory in the VM until we get
OutOfMemoryError, catch the OutOfMemoryException and throw a new
SQLException.
I think this approach is better, because of the following:
* Although it is the LOB which is taking almost all the memory in the
VM, the OutOfMemoryError may be thrown in another thread in the VM,
causing side-effects on other connections or on the application itself.
* We may actually go out of memory when trying to create a new
SQLException in the error handler for the OutOfMemoryError
I think this could be done both on the server side and the client side.
-- Andreas
