jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tako Schotanus" <quinte...@gmail.com>
Subject Re: checkForReferencesInContent implementation
Date Fri, 01 Jun 2007 08:57:40 GMT
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 <fesn@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
>
>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message