jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Frédéric Esnault <f...@legisway.com>
Subject RE: checkForReferencesInContent implementation
Date Fri, 01 Jun 2007 10:03:07 GMT


Frédéric Esnault - Ingénieur R&D
Legisway
60 boulevard de la mission Marchand
92400 Courbevoie La Défense
 
Well I have two comments.

First, I think the lock should be obtained AFTER the sessions/txs are saved/committed. If
you get the lock before, and one of the pending modifications is a trivial modification of
this particular node type (ie. adding a not mandatory property), then the pending modification
will fail to commit, as the node type is locked. The moment the node type is locked needs
careful thinking imo. The question is : is there a way to prevent new session/tx to be created
while waiting for active ones to finish?

Second, not only the node type needs to be locked, the whole repository must be locked, to
prevent user to, for example, create a content node of that particular node type. I think
this could easily be done by deep locking the repository root node, as both content and system
nodes are under the root. This would not need a specific node lock, but "only" a deep lock
on the root. Once again, this is okay for me, as the node type modification is not a common
operation.

>i am not worried about the performance of node type modifications per se.
>my comment was with regard to sandro's suggested approach of acquiring
>locks on individual node types. my concern was that this would hurt
>performance even in the
>absence of node type modifications since those locks would need to be
>acquired and
>held at least during write operations/tx commits.
>
>cheers
>stefan


Mime
View raw message