Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@jackrabbit.apache.org
Date: Thu, 21 Nov 2013 07:18:36 +0000 (UTC)
From: "Radoslaw Stachowiak (JIRA)" <jira@apache.org>
To: dev@jackrabbit.apache.org
Message-ID: <JIRA.12680453.1385018284251.6316.1385018316322@arcas>
In-Reply-To: <JIRA.12680453.1385018284251@arcas>
References: <JIRA.12680453.1385018284251@arcas>
Subject: [jira] [Created] (JCR-3698) Locking works incorrectly when used
 with JTA transactions.
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

Radoslaw Stachowiak created JCR-3698:
----------------------------------------

             Summary: Locking works incorrectly when used with JTA transactions.
                 Key: JCR-3698
                 URL: https://issues.apache.org/jira/browse/JCR-3698
             Project: Jackrabbit Content Repository
          Issue Type: Bug
          Components: jackrabbit-core, locks
    Affects Versions: 2.6.3
         Environment: JDK 7, JTA 1.1
            Reporter: Radoslaw Stachowiak


When JTA is used, locking is performed inside the transaction the session is registered in. This makes locks visible only after transaction is commited and session-scoped locks are useless.

Steps to reproduce:
1. Add a node.
1. Begin transaction.
2. Create lock for node.
3. Suspend transaction.
4. Begin new transaction.
5. Check for lock on node.
Expected: node is locked.
Actual result: node is not locked until first transaction is commited. If session-scoped lock is used, node will never be locked.

Workaround that simulates session scoped lock:
1. Suspend current transaction.
2. Begin new transaction.
3. Create lock.
4. Commit.
5. Resume suspended transaction.
6. Assign lock to resumed transaction.
7. Register Synchronization to release lock before transaction is finished.


--
This message was sent by Atlassian JIRA
(v6.1#6144)