Mailing-List: contact users-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@jackrabbit.apache.org
Received-SPF: pass (herse.apache.org: domain of lists@nabble.com designates
 72.21.53.35 as permitted sender)
Message-ID: <8847994.post@talk.nabble.com>
Date: Wed, 7 Feb 2007 07:53:07 -0800 (PST)
From: anton_slutsky <aslutsky@applevac.com>
To: users@jackrabbit.apache.org
Subject: Re: NodeTypeRegistry.checkForReferencesInContent()
In-Reply-To: <510143ac0702070724i3fa0c5c9xf2017a1b3188e888@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
References: <8054782.post@talk.nabble.com>
 <510143ac0612270732i3ce3b1cey503fcf5f9e8a2070@mail.gmail.com>
 <8074790.post@talk.nabble.com> <459D6F85.8010609@gmx.de>
 <8768745.post@talk.nabble.com> <8793775.post@talk.nabble.com>
 <8be731880702040842t6fc92949q933a761e30bd313c@mail.gmail.com>
 <8796602.post@talk.nabble.com> <8844504.post@talk.nabble.com>
 <510143ac0702070724i3fa0c5c9xf2017a1b3188e888@mail.gmail.com>


I agree, examining each node manually would be safer, but, like you said, it
probably wont scale performancewise. 

Concurrency is an issue.  I was thinking on setting a semaphore or a mutex
flag on the RepositoryImpl instance, but I was sure if it's possible to have
two RepositoryImpl instances working on the same physical repository.  From
what I've read so far, it doesnt appear that such a behavior is supported. 
If this can be confirmed to be a fact, the mutex solution should really do
the trick.

Please pardon the ignorance, but what is an improvement request, and where
can I file one? :-)

Thanks,
Anton


Jukka Zitting wrote:
> 
> Hi,
> 
> On 2/7/07, anton_slutsky <aslutsky@applevac.com> wrote:
>> So what do you guys think of my implementation?  I really hate to deploy
>> my
>> apps with customized code.  I'd rather have it out there with an
>> out-of-the-box jackrabbit.
> 
> Looks cool, though I have some concerns.
> 
> My main concern is about using search to find the node type
> references. Normally this shouldn't be a problem, but since the search
> index is a separate copy of the persisted content there is a chance of
> coherence issues. More notably the search engine is pluggable and in
> some cases it has been disabled alltogether. Using the actual item
> state and persistence managers to look for references would IMHO be
> safer, though as of now there are no access paths outside the search
> index that would perform reasonably.
> 
> Another concern is concurrency. How can we make sure that there are no
> concurrent modifications going on that might introduce new references
> to the node type in question?
> 
> I think your patch is a good starting point but we still need work to
> sort out all the relevant details. You may want to attach your patch
> to JCR-322 or file it as a separate improvement request. I'd also
> suggest that you take this thread to the developer mailing list.
> 
> BR,
> 
> Jukka Zitting
> 
> 

-- 
View this message in context: http://www.nabble.com/NodeTypeRegistry.checkForReferencesInContent%28%29-tf2882955.html#a8847994
Sent from the Jackrabbit - Users mailing list archive at Nabble.com.