jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jukka Zitting <jukka.zitt...@gmail.com>
Subject Re: Handling of InvalidItemStateException
Date Wed, 28 Oct 2009 00:56:42 GMT

On Tue, Oct 27, 2009 at 10:43 AM, Andrey Adamovich
<andrey.adamovich@yahoo.com> wrote:
> Actually at the moment journaling is disabled and we still see those issues once
> in a while (to be exact 97 out of about 350,000 node updates within 24 hours).
> But we just sometimes encounter JTA timeout/roll back exceptions and
> InvalidItemStateExceptions are always somewhere after those, but I can't prove
> from the logs the direct connection between those.

OK, thanks for the info. It might be good to have this as a bug
report, especially if you can provide some more details about your
deployment setup and the types of operations that your application is
performing. I don't have any direct ideas what could be the cause of
the problem, but perhaps we'll come up with something later.

> And we are not using JCR locks, but our own locking scheme with the help
> of ReentrantLocks. I don't remember why we have avoided JCR locks, but do
> you think JCR native locks should be better than custom (external to JCR)
> locking scheme?

The main benefit of using JCR locks is that it'll protect your content
also from clients that don't participate in your custom locking
scheme. If that's not an issue in your case, then there is not much
difference. I personally think that the programming model of JCR locks
is not very developer-friendly, so using a custom solution or a
utility tool like the Locked class in jackrabbit-jcr-commons is
probably an easier approach.


Jukka Zitting

View raw message