Force unlock FencedLock when CP subsystem is not enabled

[Ruxandra Laceanu]

Hello, 

What is the best way to force unlock a FencedLock when the CP subsystem operates in unsafe mode? 

The `sessionManagementService.forceCloseSession()` method does not work when the CP subsystem is not enabled. 

The `RaftSessionService.closeSession()` method works but this is an internal API. 

I was wondering what is the alternative? 

Thanks!

[M. Sancar Koyunlu]

Hi Ruxandra Laceanu,
We don't support force unlock for FencedLock on CP in both safe and unsafe mode. 
It will be unlocked after timeout if the session owner crashes ungracefully. Other than that, you should not need to use a force unlock.
https://docs.hazelcast.org/docs/4.1/manual/html-single/index.html#cp-sessions
You can configure the timeout via `CPSubsystemConfig.setSessionTimeToLiveSeconds(int)`

Can I learn your use case? Why do you want to use forceUnlock ? Is `sessionTimeToLiveSeconds` sufficient for your use case ?

Secondly, if you need a lock with forceUnlock, you can use IMap.lock/forceUnlock for that. Considering that you are ok with unsafe mode, IMap.lock gives the same guarantees. 

--
You received this message because you are subscribed to the Google Groups "Hazelcast" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hazelcast+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/hazelcast/4a1f39bb-4aef-4fe1-8aa1-2bba0572b1b5n%40googlegroups.com.

--

Sancar Koyunlu Software Engineer       hazelcast®     2 W 5th Ave, Ste 300 | San Mateo, CA 94402 | USA +1 (650) 521-5453 | hazelcast.com

This message contains confidential information and is intended only for the individuals named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. If verification is required, please request a hard-copy version. -Hazelcast

[Ruxandra L]

Hello,

I've seen that in this article there is an example how to force unlock a lock and it is mentioned that "The CP Subsystem also offers the ability to destroy a CP session manually. You can use this when you have the means to find out directly that a CP session owner crashed": https://hazelcast.com/blog/long-live-distributed-locks

Our scenario is the following: we have a thread that acquires a lock, does some work and then it releases the lock. The work that the thread does is not fully in our control and if it takes too long we have to kill the thread. 

When the thread is killed, we also want to release the lock that it holds but calling unlock on a different thread does not work since the new thread is not the owner of the lock.

For us the perfect solution would be that the lock is automatically released when a thread is killed but I'm not sure if this is feasible.

Do you have some suggestions what we could do in this situation?

Thank you,

Ruxandra

[M. Sancar Koyunlu]

Yes, there is a way to clean up a session but it should be used when the instance that acquires the lock is gone. And this is as you foundnd out works for only safe mode. 
But if you release a session, all the resources that instance holds will be cleaned up. This is dangerous if the instance is still alive. Someone else could be using another lock/semaphore, and that is cleaned up as well leaving you with a violation of a critical section.  
I would suggest handling the cleanup properly on the thread that acquires the lock, which is best handled by the following:

fencedLock.lock();
try {
    someWork();
} catch (InterruptedException e) {
    
} finally {
    fencedLock.unlock();
}

Even if we interrupt this thread, the finally block will always run a release the lock itself. Does that work for you?

To view this discussion on the web visit https://groups.google.com/d/msgid/hazelcast/0ecba1a3-1d94-411e-95ec-914cfa5f795fn%40googlegroups.com.

[Ruxandra L]

Hello,

Interrupting the threads does not always work for us since some threads might do some work which cannot be interrupted so we have to kill them.

We will look into using map locks as you previously suggested, this might be a good solution for us.

Thanks a lot for your help!

Ruxandra