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.
  
Well fortunately it does not take that long.
My observations are based on monitoring how many open files derby keeps (using lsof).
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 configuration).

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.

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.
  
This timeout value probably comes from java.net.SocketOptions.SO_TIMEOUT.
(Socket.setSoTimeout(int), ServerSocket.setSoTimeout(int))
It applies to situations when the following methods are underway
- ServerSocket.accept();
- SocketInputStream.read();
- DatagramSocket.receive();

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
network congestion.
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.

- rami