We are considering pessimistic locking for our project (SELECT ... FOR UPDATE
); as we are used to optimistic locking, we are afraid about the operation of the server being blocked on such a lock (lock not getting released ever).
The most common concern that people have is obviously deadlocks, however we have another concern: what if the client dies, or looses connection to the server, while holding a SELECT ... FOR UPDATE
lock?
In many cases it would not be relevant because if the client dies the application dies, however in this case we will have a cluster of servers with failover, so we wouldn't want other nodes in the cluster to be overly affected if one node dies.
On this topic I have found this 2003 message, concerning postgreSQL: http://www.postgresql.org/message-id/3E81D7F0.2010604@xythos.com
We have also tested the tcp_keepalives_idle
postgreSQL configuration parameter, and confirmed that if we leave it low enough and kill the client, the lock gets released. However if we didn't touch that parameter, the lock did not get released (but maybe we didn't wait long enough).
And that's without considering the concern raised by this 2003 message, about the difference between the lifecycle of the client application and the life-cycle of the connection pool (we'll keep the default on this but we expect each node to have its own connection pool, no sharing across the cluster).
The problem gets even more complicated because we intend to support several database servers (at least Microsoft SQL Server and PostgreSQL, possibly Oracle).
Our solution would use JavaEE and Glassfish as an application server.
So to summarize the question: Is it safe to assume that apart from deadlocks, it is not possible that a lock stays held forever, the lock will be released after a reasonably short time (which range of duration?), even in case of a sudden death or loss of connectivity to a client holding a lock?