Hi,
We have several services in our app framework that we want to use a cluster singleton. Our approach to this was to use Objectdb's pessimestic locking. This seems to work, but if the owner of the current pessimestic lock abruptly quits without releasing the lock it doesn't get released.
Is there anyway the server can detect that a client (lock owner is no longer connected) and therefore release the lock ?
Thank you
Paul Newman
It may be possible to add support for automatic release of locks in such cases, but it may also require disabling another feature - automatic resuming of a failed connection by the client. Currently in case of a failed connection the server can still accept requests for reconnecting in a transparent way, and therefore can never assume that a client is totally dead and its locks can be released.
A possible solution (which is currently not implemented) is to use pessimistic locking with expiration time. For example, if you know that transactions that need that specific lock take no more than 1-2 seconds to complete, then setting an expiration time of 5 seconds should be safe, and if the locking client unexpectedly fails during that transaction (which is expected to be rare), the locking time will still be short.
We can add support of either expiration time for locks, or alternatively request for lock release as soon as the connection is broken.
Hi
Since I want to use Pessimistic Lock as a way of enforcing a cluster wide singleton of services, a pessimistic lock will potentially last forever or until the particular service goes down and therefore another one will take its place. So in my case the last suggestion would be the best for me. Namely a way to release the lock when a connection is broken ... in case there's a very temporary break, could the lock be released say 5 or 10 seconds after the connection has broken.
As a side note, I did some tests yesterday to calculate resource availability and I'm REALY impressed with the performance and stability of objectdb server. We've tried various in-memory solutions and Objectdb blows them away in our particular use case.
Kind regards
Paul Newman
Good to hear that ObjectDB works well for you.
The combination of a broken connection with some delay seems logical, and hopefully could be implemented in one of the next builds.
Build 2.6.7_03 adds automatic release of pessimistic locks on client-server disconnection.
The locks are released by the server as soon as the client disconnects (with no delay), but if the client later reconnects it will try to achieve automatically all the locks that it had (an exception is thrown if it fails).
