You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by "Claus Köll (JIRA)" <ji...@apache.org> on 2016/07/27 12:13:20 UTC
[jira] [Updated] (JCR-3999) Possibility for a Deadlock in
FineGrainedISMLocking in a XA Environment
[ 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)