jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <Sascha.The...@bosch-si.com>
Subject AW: jcr:lockOwner not null but node.isLocked == false
Date Wed, 23 Nov 2011 09:04:58 GMT
Hi all,

I can now reproduce the problem and it is definitely caused by the upgrade from 1.6.2 to 2.2.9:

Lock a node in Jackrabbit 1.6.2 with node.lock(true, false). That is a deep lock, not session-scoped.
Then upgrade to Jackrabbit 2.2.9 and check the node with node.isLocked.
Now node.isLocked() returns false (wrong!) and node.getProperty("jcr:lockOwner") is set.

I will raise a bug report for this issue.



-----Ursprüngliche Nachricht-----
Von: Sascha.Theves@bosch-si.com [mailto:Sascha.Theves@bosch-si.com] 
Gesendet: Dienstag, 22. November 2011 18:38
An: users@jackrabbit.apache.org
Betreff: AW: jcr:lockOwner not null but node.isLocked == false

> Can you confirm the actual state of the node? Try and lock a node and
see if
> It works or throws an ex.  Also try using the jcr2 methods:

> session.getWorkspace().getLockManager().isLocked(path)
> plus unlock()/lock()

I can now say that the node is not locked in Jackrabbit`s point of view.
Node.isLocked=false and
session.getWorkspace().getLockManager().isLocked(path)=false. It is
possible to lock the node but it is not possible to unlock the node.
Unlocking the node throws a LockException (Node not locked). Locking the
node returns a lock token that we already obtained when the node was
locked for the first time. I can confirm that is exactly the same token
because we store the tokens in a relational database and we get now
exceptions because the lock token already exists in our database. If I
lock the node, everything is fine now. Node.isLocked == true and if I
unlock the node node.isLocked=false and
node.hasProperty("jcr:lockOwner") == false, like I would expect it.

It seems that Jackrabbit has just 'forgotten' what was locked and what
not. In my opinion it must be a bug because the node state
node.getProperty("jcr:lockOwner") != null && node.isLocked==false can`t
be correct.

I cannot reproduce the problem with a complete fresh setup. It seems
that the problem only occurs when upgrading to Jackrabbit 2.2.9 and
using the database from Jackrabbit 1.6.

For me it is very important to know a workaround for the problem. Maybe
I have to re-lock everything where the jcr:lockOwner property is set and
where node.isLocked=false? What do you think? Do you need any other
information? Should I report a bug?

> Also might be interesting if sql2 returns a different set, something
> select * from [my:elementNodeType] AS s WHERE s.[my:att] = 'SomeValue'
> s.[jcr:lockOwner] IS NOT NULL

Didn`t tried that so far but I think the query language makes no
difference because if I obtain such a node via
session.getRootNode().getNode(path) the result is the same
(lockOwner!=null && nodel.isLocked=false) and here I haven`t used any
query language.

Thanks for your help!


View raw message