You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by Dave Crooke <dc...@hyper9.com> on 2009/11/07 00:53:18 UTC

OPT FYI: Hanging transaction in 1.5.x, whither OCM?

Hi folks

Just in case anyone is interested .... 

We are making very light use of Jackrabbit 1.5.3 with OCM in our
environment. 

1. We tripped over an issue whereby DatabasePersistenceManager.java
keeps an uncommitted transaction open at all times. I had a rummage
around JIRA but I couldn't find anything similar reported.

I couldn't track down the missing commit, so my workaround was to simply
patch it to non-transactional behavior (using JDBC auto-commit), and
this works fine in our environment including stress testing our use of
Jackrabbit, but we're not using features like versioning which may
depend on real transactional semantics.

2. We found that OCM-5 was causing a noticeable memory leak in our
environment, and the patch suggested in the ticket does fix it.

Is Jackrabbit OCM still a live project? There doesn't seem to have been
much activity since the refactor for Jackrabbit 1.6.0


Cheers
Dave




Re: OPT FYI: Hanging transaction in 1.5.x, whither OCM?

Posted by Marcel Reutegger <ma...@gmx.net>.
On Sat, Nov 7, 2009 at 00:53, Dave Crooke <dc...@hyper9.com> wrote:
> Just in case anyone is interested ....

I am ...

> 1. We tripped over an issue whereby DatabasePersistenceManager.java keeps an
> uncommitted transaction open at all times. I had a rummage around JIRA but I
> couldn't find anything similar reported.

are you able to reproduce the issue? can you please provide a thread
dump of the JVM when the issue occurs?

> I couldn't track down the missing commit, so my workaround was to simply
> patch it to non-transactional behavior (using JDBC auto-commit), and this
> works fine in our environment including stress testing our use of
> Jackrabbit, but we're not using features like versioning which may depend on
> real transactional semantics.

please note that you also lose atomicity of jackrabbit saves/commits,
which may leave you with an inconsistency in the workspace when an
error occurs while storing a set of changes.

regards
 marcel