Hi, On Tue, Oct 27, 2009 at 10:43 AM, Andrey Adamovich <[email protected]> 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. BR, Jukka Zitting
