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

TransactionalMap containsKey() blocks when key was previosuly locked by getForUpdate() #7588

Closed
dmitrymz opened this issue Feb 24, 2016 · 2 comments

Comments

Projects
None yet
3 participants
@dmitrymz
Copy link

commented Feb 24, 2016

I wanted to check for object existence before calling getForUpdate().
Reason: hazelcast lockAndGet() (invoked from getForUpdate()) throws too generic TransactionException("Transaction couldn't obtain lock for the key") in case of failing to lock non-existing object, which is confusing, and hard to distinguish from important TransactionExceptions

    private V getByKey(TransactionalMap<String, V> region, String key) {
        return region.containsKey(key) ? region.getForUpdate(key) : null;
    }

however, the problem is that if the key is already locked by previous getForUpdate() then
containsKey() method blocks.

I think this is erroneous behavior as containsKey() is a read-only operation that should not be blocked.
It doesn't matter if its result comes from inside or outside of transaction.

Please, advise of what is the right way to check for object existence before getForUpdate().
(Of course it would be great for lockAndGet to return some meaningful exception in case of object not found)

tried on v3.5.5

@jerrinot jerrinot added this to the 3.7 milestone Feb 24, 2016

@gurbuzali gurbuzali self-assigned this Feb 24, 2016

@gurbuzali

This comment has been minimized.

Copy link
Member

commented Feb 24, 2016

Hi,
lockAndGet does not throw exception if the object(key) does not exists. That exception you are seeing (TransactionException("Transaction couldn't obtain lock for the key")) is a serious exception, it means somehow hazelcast couldn't locked the key (probably it is already locked by another transaction).

So you do not need to check for existence of an object.

Regarding the blocking behavior of read-only operations in transactions, it is there by design to accomplish the atomicity of the transactions. We are planning to redesign this in 3.7.

Thank you

@jerrinot

This comment has been minimized.

Copy link
Contributor

commented May 23, 2016

fixed by #7483.

@jerrinot jerrinot closed this May 23, 2016

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.