[
https://issues.apache.org/jira/browse/JCR-2679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12894067#action_12894067
]
Hugo Lassiège commented on JCR-2679:
------------------------------------
Hi,
(I'm working with Laurent)
We didn't test it yet, I'll try next week.
However, even in the threadump I saw a lot of threads trying to acquire a lock,
the deadlocks concerns the OraclePersistenceManager and not the part involved
in FineGrainedISMLocking.
In the thread dump we have two threads blocked by :
{code}
Thread: ajp-0.0.0.0-8119-33 : priority:5, demon:true, threadId:2858,
threadState:BLOCKED,
lockName:org.apache.jackrabbit.core.persistence.bundle.oraclepersistencemana...@1c390b8
org.apache.jackrabbit.core.persistence.bundle.AbstractBundlePersistenceManager.exists(AbstractBundlePersistenceManager.java:474)
org.apache.jackrabbit.core.state.SharedItemStateManager.hasNonVirtualItemState(SharedItemStateManager.java:1409)
{code}
There is another issue (JCR-2345) which seems to be related and which is not
resolved.
Do you know if the OraclePersistenceManager could be involved in our problem ?
And if we could use a workaround for that ? (have a queue for document creation
for example)
> Lock Problem when accessing JCR
> -------------------------------
>
> Key: JCR-2679
> URL: https://issues.apache.org/jira/browse/JCR-2679
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Affects Versions: 1.5.3, 1.6.2
> Environment: JBOSS 4.2.3 on jre 1.5.0_15 with XA transactions and
> Oracle10g
> Reporter: Laurent Prevosto
> Priority: Critical
> Attachments: repository-prod.xml, thread_dump.txt, workspace.xml
>
>
> Hi,
> We're using Jackrabbit 1.6.2 as an internal CMS in an application we
> developped.
> It runs in JBOSS 4.2.3 on jre 1.5.0_15 with XA transactions and Oracle10g
> We have about 15 users adding / deleting files in the repository.
> 30 others just do read only CMS access and other stuff.
> Things work fine except that sometimes, suddenly everything gets stuck and
> all we have left is those kind of errors :
> [org.apache.jackrabbit.core.query.lucene.NodeIteratorImpl] : Exception
> retrieving Node with UUID : XXXXXXX-XXX-etc: javax.jcr.ItemNotFoundException:
> XXXXXXX-XXX-etc
> All our JCR connections are now dead. If we restart JBOSS, things get back to
> normal, until the next crash.
> It looks like the bug usually happens when this kind of sequence takes place
> (though that may not be the only one) :
> XA transaction begins
> filenode1 gets deleted
> filenode2 gets deleted
> other oracle stuff takes place... and fails
> XA rollbacks.
> => JCR is dead.
> At that point, "touching" the datasource has it reinitialised by JBOSS but
> unfortunately the lock is still there : JBOSS has to be restarted.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
