Well fortunately it does not take that long.
It's not supposed to hang, but if the transaction is large and has
performed many updates, it may take some time to undo all the
changes. It could potentially take as much time as it took to execute
the transaction in the first place.
My observations are based on monitoring how many open files derby keeps
Derby keeps open one file for every blob I insert.
If the transaction is committed the open filecount goes down to around
220 in few seconds (files derby keeps open all the time in my
When I kill the connection the open files stay open for around a minute
and then go down quickly.
So to me it seems that derby keeps waiting for something before
actually doing the rollback.
This timeout value probably comes from
I assume this means you've seen that Derby immediately prints "client
disconnected" or something in the log? Otherwise, it may take some time
before a broken connection is detected on some platforms, I would guess.
It applies to situations when the following methods are underway
I quess in my case the second method is underway when I kill the client.
But all in all it makes sense to wait some time because the delay might be due to
Does derby use nio?
I am not sure if that would change the situation.
Long story short: Derby behaves as it should. I was just thinking aloud.