You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@jackrabbit.apache.org by Frédéric Esnault <fe...@legisway.com> on 2007/06/01 10:40:33 UTC
checkForReferencesInContent implementation
For my company's project, we're currently thinking about implementing the checkForReferencesInContent method (along with the other one, checkForConflictingContent).
I saw the comment in Jira from Sandro Boehme <https://issues.apache.org/jira/secure/ViewProfile.jspa?name=sandro> (available there : https://issues.apache.org/jira/browse/JCR-322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12462752 ).
Actually this is the kind of implementation we're thinking about, as anyway you must be sure that any reference to the node type you want to unregister (for example) is not used anywhere, including in the running transactions and sessions. We plan to lock repository, wait for all transactions to be committed (or rollbacked...) and sessions to be saved, before we check for references.
A comment made by Stefan Guggisberg <https://issues.apache.org/jira/secure/ViewProfile.jspa?name=stefan%40jira> was it would cause an inacceptable performance degradation. I agree on the fact that waiting for tx and session end would definitely be potentially a pain in the ..., but the operation of unregistering a node type is (at least for us) actually a quite critical operation, not occurring every day, and made on purpose. Performance in this case is not the principal goal. IMO, the goal here is the consistency of the repository. We will think our implementation this way, but I'd like to know what the community's opinion about this strategy.
Frederic E
Re: checkForReferencesInContent implementation
Posted by Tako Schotanus <qu...@gmail.com>.
I think it would be great and I agree that in these circumstances
performance is not the most important. If in th efuture somebody else can
come up with a solution that performs well, great, but until then I will
take any (safe) implementation.
On 6/1/07, Frédéric Esnault <fe...@legisway.com> wrote:
>
>
>
> For my company's project, we're currently thinking about implementing the
> checkForReferencesInContent method (along with the other one,
> checkForConflictingContent).
>
> I saw the comment in Jira from Sandro Boehme <
> https://issues.apache.org/jira/secure/ViewProfile.jspa?name=sandro>
> (available there :
> https://issues.apache.org/jira/browse/JCR-322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12462752).
>
>
>
> Actually this is the kind of implementation we're thinking about, as
> anyway you must be sure that any reference to the node type you want to
> unregister (for example) is not used anywhere, including in the running
> transactions and sessions. We plan to lock repository, wait for all
> transactions to be committed (or rollbacked...) and sessions to be saved,
> before we check for references.
>
>
>
> A comment made by Stefan Guggisberg <
> https://issues.apache.org/jira/secure/ViewProfile.jspa?name=stefan%40jira> was
> it would cause an inacceptable performance degradation. I agree on the fact
> that waiting for tx and session end would definitely be potentially a pain
> in the ..., but the operation of unregistering a node type is (at least for
> us) actually a quite critical operation, not occurring every day, and made
> on purpose. Performance in this case is not the principal goal. IMO, the
> goal here is the consistency of the repository. We will think our
> implementation this way, but I'd like to know what the community's opinion
> about this strategy.
>
>
>
> Frederic E
>
>
>
>
RE: checkForReferencesInContent implementation
Posted by Frédéric Esnault <fe...@legisway.com>.
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
Re: checkForReferencesInContent implementation
Posted by Stefan Guggisberg <st...@gmail.com>.
On 6/1/07, Frédéric Esnault <fe...@legisway.com> wrote:
>
>
> For my company's project, we're currently thinking about implementing the checkForReferencesInContent method (along with the other one, checkForConflictingContent).
>
> I saw the comment in Jira from Sandro Boehme <https://issues.apache.org/jira/secure/ViewProfile.jspa?name=sandro> (available there : https://issues.apache.org/jira/browse/JCR-322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12462752 ).
>
>
>
> Actually this is the kind of implementation we're thinking about, as anyway you must be sure that any reference to the node type you want to unregister (for example) is not used anywhere, including in the running transactions and sessions. We plan to lock repository, wait for all transactions to be committed (or rollbacked...) and sessions to be saved, before we check for references.
>
>
>
> A comment made by Stefan Guggisberg <https://issues.apache.org/jira/secure/ViewProfile.jspa?name=stefan%40jira> was it would cause an inacceptable performance degradation. I agree on the fact that waiting for tx and session end would definitely be potentially a pain in the ..., but the operation of unregistering a node type is (at least for us) actually a quite critical operation, not occurring every day, and made on purpose. Performance in this case is not the principal goal. IMO, the goal here is the consistency of the repository. We will think our implementation this way, but I'd like to know what the community's opinion about this strategy.
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
>
>
>
> Frederic E
>
>
>
>