[
https://issues.apache.org/jira/browse/JCR-3999?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Köll updated JCR-3999:
----------------------------
Description:
We have seen a deadlock in the FineGrainedISMLocking in our XA Environment.
The deadlock will occur if the xa client connects to jackrabbit with 2
different credentials (xa-resources) during a global transaction.
If that happens the FineGrainedISMLocking will create a lock from xa-resource-1
during the prepare phase. The lock creates the SISM
in the Update.begin() Method.
The xa-resource-2 tries also to create a lock but can not allocate it because
the first created lock would be realesed in the commit phase.
The FineGrainedISMLocking should re-allocate the lock if it comes from the same
gloal transaction.
This behaviour is already implemented in the DefaultISMLocking.
> Possibility for a Deadlock in FineGrainedISMLocking in a XA Environment
> -----------------------------------------------------------------------
>
> Key: JCR-3999
> URL: https://issues.apache.org/jira/browse/JCR-3999
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-core
> Affects Versions: 2.13.1
> Reporter: Claus Köll
> Assignee: Claus Köll
> Fix For: 2.13.2
>
>
> We have seen a deadlock in the FineGrainedISMLocking in our XA Environment.
> The deadlock will occur if the xa client connects to jackrabbit with 2
> different credentials (xa-resources) during a global transaction.
> If that happens the FineGrainedISMLocking will create a lock from
> xa-resource-1 during the prepare phase. The lock creates the SISM
> in the Update.begin() Method.
> The xa-resource-2 tries also to create a lock but can not allocate it because
> the first created lock would be realesed in the commit phase.
> The FineGrainedISMLocking should re-allocate the lock if it comes from the
> same gloal transaction.
> This behaviour is already implemented in the DefaultISMLocking.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
