Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@jackrabbit.apache.org
Received-SPF: pass (asf.osuosl.org: local policy)
Message-ID: <44A3AC2C.9010507@grahamtechnology.com>
Date: Thu, 29 Jun 2006 11:32:12 +0100
From: "Rod Mackenzie" <Rod.Mackenzie@grahamtechnology.com>
User-Agent: Thunderbird 1.5.0.4 (Windows/20060516)
MIME-Version: 1.0
To: <dev@jackrabbit.apache.org>
Subject: Re: Node locked LockException
References: 
 <OF15D0299A.2FAED2E5-ON8525719C.0018E942-8525719C.001B82CB@us.ibm.com>
 <66c10f230606290044w281b8ca0w2762943a8d5e56dc@mail.gmail.com>
In-Reply-To: <66c10f230606290044w281b8ca0w2762943a8d5e56dc@mail.gmail.com>
Content-Type: text/plain;
	format=flowed;
	charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit

Hi,

I came across this problem a few weeks ago and submitted a JIRA issue 
441. I would suggest removing the lock tokens on a logout would be 
better than throwing an exception when trying to modify the node. There 
is still a LockInfo object with a reference to the old session and as 
far as I can tell no way to remove it except with a restart.

regards,
Rod


Dominique Pfister wrote:
> Hi David,
> 
> the JCR 1.0 specification is not explicit about the behaviour of
> open-scoped locks when the session currently holding the lock logs
> out. Jackrabbit clears the lock holder for the first, owning session,
> if it hasn't been changed, but not for other sessions that receive the
> lock token, which is definitely strange behaviour. So your test case
> should either throw when session2 sets the property (because the lock
> token has not been explicitely removed from session1) or never
> (because the lock token will always be silently removed from a session
> logging out). Please submit a JIRA issue.
> 
> Kind Regards
> Dominique
> 
> On 6/29/06, David Kennedy <davek@us.ibm.com> wrote:
>> I believe there is a bug in the LockManagerImpl class with regard to
>> LockToken management.  The problem is that the LockInfo listener of the
>> Session is lost.  I believe the LockManagerImpl::lockTokenAdded method
>> sets the lockHolder to the session, but doesn't add the LockInfo as a
>> listener of the session to clear out the lockHolder when the session is
>> logging out.
>>
>>                     if (info.getLockHolder() == null) {
>>                         info.setLockHolder(session);
>>                     } else {
>>
>> should be
>>
>>                     if (info.getLockHolder() == null) {
>>                 session.addListener(info);             //info must be a
>> LockInfo, not an AbstraceLockInfo
>>                         info.setLockHolder(session);
>>                     } else {
>>
>> similarly for  LockManagerImpl::lockTokenRemoved....it should remove the
>> LockInfo from the session listener list.
>>
>> Normally the listener is added in LockManagerImpl::internalLock, however
>> when the lock token is added to another session, the internalLock method
>> is not invoked.
>>
>> Here is a testcase that should evoke the exception....the exception 
>> should
>> occur on the setProperty in session3.
>>
>>     try {
>>       //Register the repository in JNDI
>>       Hashtable env = new Hashtable();
>>       env.put(Context.INITIAL_CONTEXT_FACTORY,
>> "org.apache.jackrabbit.core.jndi.provider.DummyInitialContextFactory");
>>       env.put(Context.PROVIDER_URL, "localhost");
>>       InitialContext ctx = new InitialContext(env);
>>       RegistryHelper.registerRepository(ctx, "localRep", 
>> "repository.xml",
>> ".", false);
>>       Repository rep = (Repository)ctx.lookup("localRep");
>>
>>       String userid = "user";
>>       String password = "password";
>>       String nodeName = "testLockTokens";
>>
>>       Session session1 = rep.login(new SimpleCredentials(userid,
>> password.toCharArray()));
>>       Node root = session1.getRootNode();
>>       Node testNode = root.addNode(nodeName, "nt:unstructured");
>>       testNode.addMixin("mix:lockable");
>>       testNode.setProperty("foo", "session1");
>>       session1.save();
>>       Lock lock = testNode.lock(false, false);
>>       String token = lock.getLockToken();
>>       session1.logout();
>>
>>       Session session2 = rep.login(new SimpleCredentials(userid,
>> password.toCharArray()));
>>       session2.addLockToken(token);
>>       root = session2.getRootNode();
>>       testNode = root.getNode(nodeName);
>>       testNode.setProperty("foo", "session2");
>>       session2.save();
>>       session2.logout();
>>
>>       Session session3 = rep.login(new SimpleCredentials(userid,
>> password.toCharArray()));
>>       session3.addLockToken(token);
>>       root = session3.getRootNode();
>>       testNode = root.getNode(nodeName);
>>       testNode.setProperty("foo", "session3");
>>       session3.save();
>>       session3.logout();
>>
>>       Session session4 = rep.login(new SimpleCredentials(userid,
>> password.toCharArray()));
>>       root = session4.getRootNode();
>>       testNode = root.getNode(nodeName);
>>       testNode.remove();
>>       session4.save();
>>     } catch (Exception e){
>>       e.printStackTrace();
>>     }
>>
>>
>> David
>>
> 
> 

________________________________________________________________________________
This email (and any attachments) is private and confidential, and is intended solely for the
addressee. If you have received this communication in error please remove it and inform us via
telephone or email. Although we take all possible steps to ensure mail and attachments
are free from malicious content, malware and viruses, we cannot accept any responsibility
whatsoever for any changes to content outwith our administrative bounds. The views represented
within this mail are solely the view of the author and do not reflect the views of the organisation
as a whole.
________________________________________________________________________________
Graham Technology plc                                                http://www.grahamtechnology.com
________________________________________________________________________________