views:

70

answers:

3

Is there any way to guarantee that an application won't fail to release row locks in Oracle? If I make sure to put commit statements in finally blocks, that handles the case of unexpected errors, but what if the app process just suddenly dies before it commits (or someone kicks the power cord / lan cable out).

Is there a way to have Oracle automatically roll back idle sessions after X amount of time? Or roll back when I somehow detects that the connection was lost?

From the experiments I've done, if I terminate an app process before it commits, the rows locks stay forever until I log into the database and manually kill the session.

Thanks.

A: 

I am not a DBA so I am sure you can find a better solution...

but there are certain deadlock conditions that seem to happen that will not roll back on our own. My last DBA had a process that would run every minute and kill anything that had been running more than 10 minutes.

bwawok
That's a very bad idea. If your database gets very large at all, you could very easily end up killing the gather stats job, for instance (or, worse, a backup).
Allan
Well you have to be careful what you allow it to kill, this was stuff started by an app server (which gather stats or backup would not be)
bwawok
+2  A: 

Try setting SQLNET.EXPIRE_TIME in your sqlnet.ora.

SQLNET.EXPIRE_TIME=10

From the documentation:

Purpose
To specify a time interval, in minutes, to send a check to verify that client/server connections are active.

Peter Lang
This sounds like the answer. Are there any major disadvantages to using this feature? Why doesn't Oracle do this by default? The docs list a few disadvantages but I don't see how any of them justify disabling this feature by default.
jthg
What if your queries take 2 hours to complete? :)
bwawok
According to the linked documentation, it just checks whether the client is still alive after the EXPIRE_TIME. If the client responds every time, the query can take as long as it needs.
jthg
I'm not a DBA myself, but I did not find any other disadvantages than the ones listed. Give it a try to find out if it works for you.
Peter Lang
Disadvantage is that, if you have hundreds of connections (which was frequent in the days before app servers) this 'check' could use up significant resources if the expire_time was low.
Gary
http://richard-e-hall.blogspot.com/2007/09/sqlnet-expiretime.html
Jeffrey Kemp
+1  A: 

COMMIT inside finally is probably the last thing you should do since you should (almost) never commit anything that threw an exception.

erikkallen
Oops, you're right.
jthg