[infinispan-issues] [JBoss JIRA] (ISPN-4274) Calling Advanced.Cache.lock with SKIP_LOCKING flag reports it locked the entry

[William Burns (JIRA)]

    [ https://issues.jboss.org/browse/ISPN-4274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12966864#comment-12966864 ] 

William Burns commented on ISPN-4274:
-------------------------------------

<wburns> what did you think about the exception thing btw?
<dberindei> ah right, that too
<dberindei> I tried to come up with a use case for passing a cache.withFlags(SKIP_LOCKING) to another method because it can't be modified to remove the locking
<dberindei> but the truth is I don't see a use case for skipping locking in user code at all :)
<wburns> yeah agree, but even in that case
<wburns> shouldn't we be able to detect the flag and not send the lock command?
<dberindei> isn't that what we do now?
<dberindei> I mean what my PR does?
<wburns> yes, but shouldn't that mean we are covered?
<wburns> if a user does do cache.getAdvancedCache().withFlags(SKIP_LOCKING).put(...)
<wburns> shouldn't it just do the put without locking?
<dberindei> the user can call AdvancedCache.lock()
<wburns> true, but in that case I think I would expect it to be locked
<wburns> and an exception being returned seems good to me
<dberindei> that's what I meant, I'm struggling to find a case where you'd want to call lock() explicitly and not lock anything :)
<wburns> ah gotcha
<wburns> or we could make lock always return false
<wburns> lol
<dberindei> nope, the javadoc says we can only return false with FAIL_SILENTLY :)
<wburns> haha yeah I know but it is 7.0 :)
<wburns> but you are doing this for jdg6.3 as well
<dberindei> yeah, it would be nice to get it in jdg
<wburns> I wonder if jdg requires us to lock it still then
<dberindei> well, the old code didn't lock
<dberindei> it's just that it was hidden in the LockManager, I think
<wburns> unfortunately
<wburns> it looks like it locked
<wburns> oh nvm sorry looking at wrong spot
<dberindei> yeah, LockManagerImpl:173
<wburns> I was more worried about the remote part
<dberindei> I don't think it did anything except register the tx on the remote nodes
<dberindei> the skip_locking flag was still used
<wburns> ah true, so just performance hit then
<wburns> for a weird edge case :P
<wburns> but either way returning true from lock seems wrong
<dberindei> that's true

> Calling Advanced.Cache.lock with SKIP_LOCKING flag reports it locked the entry
> ------------------------------------------------------------------------------
>
>                 Key: ISPN-4274
>                 URL: https://issues.jboss.org/browse/ISPN-4274
>             Project: Infinispan
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 6.0.2.Final
>            Reporter: William Burns
>            Assignee: Dan Berindei
>
> Currently when SKIP_LOCKING is used as a flag on the cache and the lock command is called it will not acquire the lock for the given keys no matter what.  However the command still returns true even though it hasn't acquired the lock.  We should probably throw some kind of exception or change the API documentation regarding the lock method.
> https://github.com/infinispan/infinispan/pull/2484#discussion_r12478627



--
This message was sent by Atlassian JIRA
(v6.2.3#6260)