Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Lock expiration (feature request) #297

Closed
justincranford opened this issue Oct 4, 2012 · 8 comments

Comments

Projects
None yet
4 participants
@justincranford
Copy link

commented Oct 4, 2012

*** Can you add timeToLive support for locks? ***

I am using Hazelcast 1.9.4.4 in a commercial application. The application supports application clustering via a shared database. It had distributed lock and sequence subsystems backed by shared tables in the shared database. I replaced the implementation with Hazelcast, but Hazelcast is missing one piece of functionality that would be useful to a broad audience.

If one of my Tomcat nodes acquires a lock and restarts (or crashed), the lock persists forever. I cannot destroy it, and it does not expire on its own.

If there is an existing workaround I would be open to using it. For example:

  1. Can I access existing locks via the same thread and set a timeToLive?
  2. Can I access existing locks via another thread and destroy it? I could use an auxiliary Hazelcast data structure to track the expiration times and apply them via a polling thread.

My application clusters have multiple Tomcats grabbing a lock to execute critical sections for the cluster. If a Tomcat in the cluster grabs a lock and:

  1. crashes, the lock is never released. Another Tomcats polls for expired locks and destroys them so the cluster recovers on its own.
  2. restarted, the lock is not released. At startup, the Tomcat node searches for locks previously created by that same instance (ex: by hostname) and destroys them.
@justincranford

This comment has been minimized.

Copy link
Author

commented Oct 4, 2012

Correction. Hazelcast releases locks created by a member that leaves the cluster. I still need timeToLive for locks though. Possible scenarios include grabbing a lock and forgetting to release it, or grabbing a lock and hanging forever without releasing it such as during access of a third-party application or DB.

@flozano

This comment has been minimized.

Copy link

commented Jan 13, 2013

I also think this feature would be very nice, not only for "fat" getLock() but also for IMap locks, having them with expiration would be amazing - even more if this expiration could be event-handled!

In an ideal world, locks should be unlocked after each protected operation is finished but, in reality, bugs happen, and in some other complex scenarios it's easy to leave locks unintendedly locked. By having a "timeout" for locks and being able to handle them, these scenarios can be found easily and, when you find them in production, it's nice if they are mitigated by the timeout.

@naglafar

This comment has been minimized.

Copy link

commented May 20, 2013

Yeah this get a thumbs up from me this would be a very handy feature. We have had a few very nasty production bugs which this would enables us to work around.

@mdogan

This comment has been minimized.

Copy link
Member

commented Jul 12, 2013

Fixed in 3.0.

@mdogan mdogan closed this Jul 12, 2013

@flozano

This comment has been minimized.

Copy link

commented Aug 11, 2013

Maybe I'm misunderstanding the solution given in 3.0, but what tryLock looks like now is:

boolean tryLock(K key, long time, TimeUnit timeunit) throws InterruptedException;

What I'm looking for would be:

boolean tryLock(K key, long time, TimeUnit timeunit, long lockExpirationTime, TimeUnit lockExpirationTimeunit)

@mdogan

This comment has been minimized.

Copy link
Member

commented Aug 11, 2013

Lock expiration is not available for tryLock() methods at the moment. Only
lock(expirationTime) version is available.

@flozano

This comment has been minimized.

Copy link

commented Aug 11, 2013

I see... so for now it's either expiration or max-time waiting... :/

Any chance of this getting implemented in 3.0?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.