You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-user@db.apache.org by Rami Ojares / PDF-Comics Oy <ra...@absinth.fi> on 2010/01/12 16:52:15 UTC

derby rollback

I create a large transaction.
Keep adding to it.
And BANG I kill the client process suddenly.
It seems that the transaction keeps hanging on inside derby for some 
time (maybe a minute or so).
Is this the way it's supposed to be?
Derby certainly detects that the connection was broken.
Does derby wait for the client to reconnect or something?

For concurrency's and responsiveness' sake it would be better to start 
the rollback immediately.

- rami

Re: derby rollback

Posted by Rami Ojares / PDF-Comics Oy <ra...@absinth.fi>.
> 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)| 
<http://java.sun.com/javase/6/docs/api/java/net/Socket.html#setSoTimeout%28int%29>, 
|ServerSocket.setSoTimeout(int)| 
<http://java.sun.com/javase/6/docs/api/java/net/ServerSocket.html#setSoTimeout%28int%29>)
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


Re: derby rollback

Posted by Knut Anders Hatlen <Kn...@Sun.COM>.
Rami Ojares / PDF-Comics Oy <ra...@absinth.fi> writes:

> I create a large transaction.
> Keep adding to it.
> And BANG I kill the client process suddenly.
> It seems that the transaction keeps hanging on inside derby for some
> time (maybe a minute or so).
> Is this the way it's supposed to be?

Hi Rami,

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.

> Derby certainly detects that the connection was broken.

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.

> Does derby wait for the client to reconnect or something?

No, it shouldn't do that.

-- 
Knut Anders