You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@jackrabbit.apache.org by Gamba <ho...@handelshof.de> on 2009/08/20 07:42:20 UTC
Own nodes with mix:lockable
Hi,
I have my own node-types extending nt:folder and nt:file:
[hmg:folder] > nt:folder
- * (string)
- * (string) multiple
- * (boolean)
- * (boolean) multiple
- * (double)
- * (double) multiple
- * (long)
- * (long) multiple
- * (date)
- * (date) multiple
[hmg:file] > nt:file
- * (string)
- * (string) multiple
- * (boolean)
- * (boolean) multiple
- * (double)
- * (double) multiple
- * (long)
- * (long) multiple
- * (date)
- * (date) multiple
I wonder if it would be possible to add a mixin-type at creation time, e. g.
mix:lockable ?
Where must it be places in my notation?
Thx
Gamba
--
View this message in context: http://www.nabble.com/Own-nodes-with-mix%3Alockable-tp25056308p25056308.html
Sent from the Jackrabbit - Users mailing list archive at Nabble.com.
Re: Own nodes with mix:lockable
Posted by Gamba <ho...@handelshof.de>.
The original test was without a without a jira bug from
within a session bean. Same code but injected repository.
Can't file a JIRA bug because I'm straight on the way to austria
on holiday.
But in two weeks, that would be possible.
What about the general locking. Is my experience correct ...
(Last sentences on my last note ...) ?
Alexander Klimetschek wrote:
>
> On Fri, Aug 21, 2009 at 8:55 AM, Gamba<ho...@handelshof.de> wrote:
>>
>> Ok, that's correct. But the behaviour is the same as before, when I login
>> with a new session:
>>
>> ...
>>
>> // only with this snippet unlocking is performed
>> //nodeToLock.unlock();
>> sessionLocal.logout();
>> sessionLocal = null;
>>
>> // After logout, we have to create a new session to check the locking.
>> // Does only make sense in multiple transactions?
>> sessionLocal = repository.login (new SimpleCredentials("..",
>> "..".toCharArray()), "default");
>>
>> // Get node to update ...
>> Node rootNode2 = sessionLocal.getRootNode();
>> Node nodeFree = rootNode2.getNode("HMG");
>>
>> assertFalse("Node is still logged, after session-logout",
>> nodeFree.isLocked());
>> sessionLocal.logout();
>>
>> => Exception: Node (nodeFree) is still locked. I expected that the lock
>> would be released
>> after session-logout because the sessionScoped-Param is ste to true.
>
> Looks like a bug, maybe only in the RMI client, as the jcr tests cover
> that: [1] (testLogout()).
>
> Do you use the latest version of Jackrabbit (1.6.x)? Could you test it
> without RMI and/or file a JIRA bug? Thanks!
>
> [1]
> http://svn.apache.org/viewvc/jackrabbit/branches/1.6/jackrabbit-jcr-tests/src/main/java/org/apache/jackrabbit/test/api/lock/LockTest.java?revision=801262
>
> Regards,
> Alex
>
> --
> Alexander Klimetschek
> alexander.klimetschek@day.com
>
>
--
View this message in context: http://www.nabble.com/Own-nodes-with-mix%3Alockable-tp25056308p25078682.html
Sent from the Jackrabbit - Users mailing list archive at Nabble.com.
Re: Own nodes with mix:lockable
Posted by Alexander Klimetschek <ak...@day.com>.
On Fri, Aug 21, 2009 at 8:55 AM, Gamba<ho...@handelshof.de> wrote:
>
> Ok, that's correct. But the behaviour is the same as before, when I login
> with a new session:
>
> ...
>
> // only with this snippet unlocking is performed
> //nodeToLock.unlock();
> sessionLocal.logout();
> sessionLocal = null;
>
> // After logout, we have to create a new session to check the locking.
> // Does only make sense in multiple transactions?
> sessionLocal = repository.login (new SimpleCredentials("..",
> "..".toCharArray()), "default");
>
> // Get node to update ...
> Node rootNode2 = sessionLocal.getRootNode();
> Node nodeFree = rootNode2.getNode("HMG");
>
> assertFalse("Node is still logged, after session-logout",
> nodeFree.isLocked());
> sessionLocal.logout();
>
> => Exception: Node (nodeFree) is still locked. I expected that the lock
> would be released
> after session-logout because the sessionScoped-Param is ste to true.
Looks like a bug, maybe only in the RMI client, as the jcr tests cover
that: [1] (testLogout()).
Do you use the latest version of Jackrabbit (1.6.x)? Could you test it
without RMI and/or file a JIRA bug? Thanks!
[1] http://svn.apache.org/viewvc/jackrabbit/branches/1.6/jackrabbit-jcr-tests/src/main/java/org/apache/jackrabbit/test/api/lock/LockTest.java?revision=801262
Regards,
Alex
--
Alexander Klimetschek
alexander.klimetschek@day.com
Re: Own nodes with mix:lockable
Posted by Gamba <ho...@handelshof.de>.
Ok, that's correct. But the behaviour is the same as before, when I login
with a new session:
...
// only with this snippet unlocking is performed
//nodeToLock.unlock();
sessionLocal.logout();
sessionLocal = null;
// After logout, we have to create a new session to check the locking.
// Does only make sense in multiple transactions?
sessionLocal = repository.login (new SimpleCredentials("..",
"..".toCharArray()), "default");
// Get node to update ...
Node rootNode2 = sessionLocal.getRootNode();
Node nodeFree = rootNode2.getNode("HMG");
assertFalse("Node is still logged, after session-logout",
nodeFree.isLocked());
sessionLocal.logout();
=> Exception: Node (nodeFree) is still locked. I expected that the lock
would be released
after session-logout because the sessionScoped-Param is ste to true.
So at all, must I lock my Nodes on concurrent updates?
I have a j2ee-environment and retreiving a session per request.
It could be possible, that two clients add or update the same
node.
Is there any trouble to expect in addition to the "lost-update-problem"?
If I understand it right (spec 8.4.10) a lock is only necessary and useful
over more than one transaction. But the updates only made in one transaction
and one instance of my session-bean. At the end of the bean-method
the session will be saved an performs a logout. After that the transaction
is committed. And after that the changes are persistent.
Thx
Gamba
Alexander Klimetschek wrote:
>
> On Thu, Aug 20, 2009 at 9:58 AM, Gamba<ho...@handelshof.de> wrote:
>> // stop node-locking on logout(), because of session-scoped lock
>> ... I
>> thought ...
>> session.save();
>> session.logout();
>>
>> // LockExcpetion is thrown
>> assertFalse("Node is still logged, after session-logout",
>> nodeToLock.isLocked());
>> }
>
> I think the error lies in this test: after logging out, the node
> objects are not valid for usage anymore. To test it properly, create a
> new session, re-fetch the node in question and then check the
> isLocked() method.
>
> Regards,
> Alex
>
> --
> Alexander Klimetschek
> alexander.klimetschek@day.com
>
>
--
View this message in context: http://www.nabble.com/Own-nodes-with-mix%3Alockable-tp25056308p25075027.html
Sent from the Jackrabbit - Users mailing list archive at Nabble.com.
Re: Own nodes with mix:lockable
Posted by Alexander Klimetschek <ak...@day.com>.
On Thu, Aug 20, 2009 at 9:58 AM, Gamba<ho...@handelshof.de> wrote:
> // stop node-locking on logout(), because of session-scoped lock ... I
> thought ...
> session.save();
> session.logout();
>
> // LockExcpetion is thrown
> assertFalse("Node is still logged, after session-logout",
> nodeToLock.isLocked());
> }
I think the error lies in this test: after logging out, the node
objects are not valid for usage anymore. To test it properly, create a
new session, re-fetch the node in question and then check the
isLocked() method.
Regards,
Alex
--
Alexander Klimetschek
alexander.klimetschek@day.com
Re: Own nodes with mix:lockable
Posted by Gamba <ho...@handelshof.de>.
Here is my Test. I'm using a Junit-Test and the rmi-server-jar of jackrabbit.
But the result is the same. The nod I locked is still locked after the
session.logout():
@Test
public void testSessionScopedLock()
throws Exception
{
Context context = new InitialContext();
Repository repository;
Session session;
// Get Repository-Instance over RMI
ClientAdapterFactory adapter = new ClientAdapterFactory();
RemoteRepository rr = (RemoteRepository)
context.lookup("jnp://localhost:1099/jcrServer");
repository = adapter.getRepository(rr);
// Get a session
session = repository.login (new SimpleCredentials("portal",
"edv9052".toCharArray()), "default");
// Get node to update ...
Node rootNode = session.getRootNode();
Node nodeToLock = rootNode.getNode("HMG");
// start node-locking
nodeToLock.lock(true, true);
// Ensure that folder does not exist
if (!nodeToLock.hasNode("TEST")) {
nodeToLock.addNode("TEST", "hmg:folder");
// only with this snippet unlocking is performed
// nodeToLock.unlock();
}
// stop node-locking on logout(), because of session-scoped lock ... I
thought ...
session.save();
session.logout();
// LockExcpetion is thrown
assertFalse("Node is still logged, after session-logout",
nodeToLock.isLocked());
}
--
View this message in context: http://www.nabble.com/Own-nodes-with-mix%3Alockable-tp25056308p25057614.html
Sent from the Jackrabbit - Users mailing list archive at Nabble.com.
Re: Own nodes with mix:lockable
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Thu, Aug 20, 2009 at 8:22 AM, Gamba<ho...@handelshof.de> wrote:
> Just found it. I need to separate mix:lockable by comma from
> my own types. Then all types hmmg:folder are creates as lockable.
Yes, that's correct.
> I get a lock with myNode.getLock(true, true).
>
> Thought that the second param called "isSessionScoped" means, that
> after calling session.logout() the lock will be removed, but my node
> is still locked ....
That's how session-scoped locks are supposed to work. I don't see
anything obviously wrong with the code snippet, but then again it
doesn't show where the error occurs.
Can you try to reduce the problem to a simple test case that shows
exactly where the behaviour is different than what you'd expect?
BR,
Jukka Zitting
Re: Own nodes with mix:lockable
Posted by Gamba <ho...@handelshof.de>.
Just found it. I need to separate mix:lockable by comma from
my own types. Then all types hmmg:folder are creates as lockable.
I get a lock with myNode.getLock(true, true).
Thought that the second param called "isSessionScoped" means, that
after calling session.logout() the lock will be removed, but my node
is still locked .... I'm using an jboss-application server an the code
is from a stateless-session-bean:
try {
Node rootNode = session.getRootNode();
lastNodeInTree = rootNode.getNode(pathLocal);
lastNodeInTree.lock(false, true);
if (!lastNodeInTree.hasNode(name)) {
lastNodeInTree.addNode(name, "hmg:folder");
}
...
session.save();
}
catch (RepositoryException re) {
...
}
finally {
if (session != null) {
session.logout();
}
}
Gamba wrote:
>
> Hi,
>
> I have my own node-types extending nt:folder and nt:file:
>
> [hmg:folder] > nt:folder
> - * (string)
> - * (string) multiple
> - * (boolean)
> - * (boolean) multiple
> - * (double)
> - * (double) multiple
> - * (long)
> - * (long) multiple
> - * (date)
> - * (date) multiple
>
>
> [hmg:file] > nt:file
> - * (string)
> - * (string) multiple
> - * (boolean)
> - * (boolean) multiple
> - * (double)
> - * (double) multiple
> - * (long)
> - * (long) multiple
> - * (date)
> - * (date) multiple
>
> I wonder if it would be possible to add a mixin-type at creation time, e.
> g. mix:lockable ?
> Where must it be places in my notation?
>
> Thx
> Gamba
>
>
--
View this message in context: http://www.nabble.com/Own-nodes-with-mix%3Alockable-tp25056308p25056614.html
Sent from the Jackrabbit - Users mailing list archive at Nabble.com.