db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rami Ojares / PDF-Comics Oy <r...@absinth.fi>
Subject Re: derby rollback
Date Tue, 12 Jan 2010 16:52:57 GMT

> 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 

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.

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

View raw message