You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by "Bertrand Delacretaz (JIRA)" <ji...@apache.org> on 2007/06/05 12:21:26 UTC
[jira] Created: (JCR-962) Deadlocks in
ConcurrentVersioningWithTransactionsTest
Deadlocks in ConcurrentVersioningWithTransactionsTest
-----------------------------------------------------
Key: JCR-962
URL: https://issues.apache.org/jira/browse/JCR-962
Project: Jackrabbit
Issue Type: Bug
Components: core
Reporter: Bertrand Delacretaz
Patch follows for a ConcurrentVersioningWithTransactionsTest, based on the existing ConcurrentVersioningTest but using transactions around the versioning operations.
On my macbook, running the test with CONCURRENCY = 100 and NUM_OPERATIONS = 100 causes a deadlock after a few seconds, thread dumps follow.
Note that I had to ignore StaleItemStateException (which is probably justified, due to not locking stuff IIUC) to let the threads run long enough to show the problem.
Running the test a few times showed the same locking pattern several times: some threads are locked at line 87 (session.save(), no transaction) while others are at line 93 (transaction.commit()), in testConcurrentCheckinInTransaction():
80 public void testConcurrentCheckinInTransaction() throws RepositoryException {
81 runTask(new Task() {
82 public void execute(Session session, Node test) throws RepositoryException {
83 int i = 0;
84 try {
85 Node n = test.addNode("test");
86 n.addMixin(mixVersionable);
87 session.save();
88 for (i = 0; i < NUM_OPERATIONS / CONCURRENCY; i++) {
89 final UserTransaction utx = new UserTransactionImpl(test.getSession());
90 utx.begin();
91 n.checkout();
92 n.checkin();
93 utx.commit();
94 }
95 n.checkout();
96 } catch (Exception e) {
97 final String threadName = Thread.currentThread().getName();
98 final Throwable deepCause = getLevel2Cause(e);
99 if(deepCause!=null && deepCause instanceof StaleItemStateException) {
100 // ignore
101 } else {
102 throw new RepositoryException(threadName + ", i=" + i + ":" + e.getClass().getName(), e);
103 }
104 }
105 }
106 }, CONCURRENCY);
107 }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-962) Deadlocks in
ConcurrentVersioningWithTransactionsTest
Posted by "Jukka Zitting (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jukka Zitting updated JCR-962:
------------------------------
Fix Version/s: (was: 1.4)
1.3.2
Merged to the 1.3 branch in revision 581177.
> Deadlocks in ConcurrentVersioningWithTransactionsTest
> -----------------------------------------------------
>
> Key: JCR-962
> URL: https://issues.apache.org/jira/browse/JCR-962
> Project: Jackrabbit
> Issue Type: Bug
> Components: jackrabbit-core
> Reporter: Bertrand Delacretaz
> Fix For: 1.3.2
>
> Attachments: 10-threads-dump.txt, 100-threads-dump.txt, deadlocked-threads.txt, JCR-962-ConcurrentVersioningWithTransactionsTest.patch, JCR-962-fix.patch
>
>
> Patch follows for a ConcurrentVersioningWithTransactionsTest, based on the existing ConcurrentVersioningTest but using transactions around the versioning operations.
> On my macbook, running the test with CONCURRENCY = 100 and NUM_OPERATIONS = 100 causes a deadlock after a few seconds, thread dumps follow.
> Note that I had to ignore StaleItemStateException (which is probably justified, due to not locking stuff IIUC) to let the threads run long enough to show the problem.
> Running the test a few times showed the same locking pattern several times: some threads are locked at line 87 (session.save(), no transaction) while others are at line 93 (transaction.commit()), in testConcurrentCheckinInTransaction():
> 80 public void testConcurrentCheckinInTransaction() throws RepositoryException {
> 81 runTask(new Task() {
> 82 public void execute(Session session, Node test) throws RepositoryException {
> 83 int i = 0;
> 84 try {
> 85 Node n = test.addNode("test");
> 86 n.addMixin(mixVersionable);
> 87 session.save();
> 88 for (i = 0; i < NUM_OPERATIONS / CONCURRENCY; i++) {
> 89 final UserTransaction utx = new UserTransactionImpl(test.getSession());
> 90 utx.begin();
> 91 n.checkout();
> 92 n.checkin();
> 93 utx.commit();
> 94 }
> 95 n.checkout();
> 96 } catch (Exception e) {
> 97 final String threadName = Thread.currentThread().getName();
> 98 final Throwable deepCause = getLevel2Cause(e);
> 99 if(deepCause!=null && deepCause instanceof StaleItemStateException) {
> 100 // ignore
> 101 } else {
> 102 throw new RepositoryException(threadName + ", i=" + i + ":" + e.getClass().getName(), e);
> 103 }
> 104 }
> 105 }
> 106 }, CONCURRENCY);
> 107 }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-962) Deadlocks in
ConcurrentVersioningWithTransactionsTest
Posted by "Bertrand Delacretaz (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Bertrand Delacretaz updated JCR-962:
------------------------------------
Attachment: JCR-962-ConcurrentVersioningWithTransactionsTest.patch
ConcurrentVersioningWithTransactionsTest patch, must be enabled in org.apache.jackrabbit.core.TestAll
> Deadlocks in ConcurrentVersioningWithTransactionsTest
> -----------------------------------------------------
>
> Key: JCR-962
> URL: https://issues.apache.org/jira/browse/JCR-962
> Project: Jackrabbit
> Issue Type: Bug
> Components: core
> Reporter: Bertrand Delacretaz
> Attachments: 10-threads-dump.txt, JCR-962-ConcurrentVersioningWithTransactionsTest.patch
>
>
> Patch follows for a ConcurrentVersioningWithTransactionsTest, based on the existing ConcurrentVersioningTest but using transactions around the versioning operations.
> On my macbook, running the test with CONCURRENCY = 100 and NUM_OPERATIONS = 100 causes a deadlock after a few seconds, thread dumps follow.
> Note that I had to ignore StaleItemStateException (which is probably justified, due to not locking stuff IIUC) to let the threads run long enough to show the problem.
> Running the test a few times showed the same locking pattern several times: some threads are locked at line 87 (session.save(), no transaction) while others are at line 93 (transaction.commit()), in testConcurrentCheckinInTransaction():
> 80 public void testConcurrentCheckinInTransaction() throws RepositoryException {
> 81 runTask(new Task() {
> 82 public void execute(Session session, Node test) throws RepositoryException {
> 83 int i = 0;
> 84 try {
> 85 Node n = test.addNode("test");
> 86 n.addMixin(mixVersionable);
> 87 session.save();
> 88 for (i = 0; i < NUM_OPERATIONS / CONCURRENCY; i++) {
> 89 final UserTransaction utx = new UserTransactionImpl(test.getSession());
> 90 utx.begin();
> 91 n.checkout();
> 92 n.checkin();
> 93 utx.commit();
> 94 }
> 95 n.checkout();
> 96 } catch (Exception e) {
> 97 final String threadName = Thread.currentThread().getName();
> 98 final Throwable deepCause = getLevel2Cause(e);
> 99 if(deepCause!=null && deepCause instanceof StaleItemStateException) {
> 100 // ignore
> 101 } else {
> 102 throw new RepositoryException(threadName + ", i=" + i + ":" + e.getClass().getName(), e);
> 103 }
> 104 }
> 105 }
> 106 }, CONCURRENCY);
> 107 }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-962) Deadlocks in
ConcurrentVersioningWithTransactionsTest
Posted by "Bertrand Delacretaz (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Bertrand Delacretaz updated JCR-962:
------------------------------------
Attachment: 100-threads-dump.txt
Deadlocked threads dump with 100 concurrent tasks
> Deadlocks in ConcurrentVersioningWithTransactionsTest
> -----------------------------------------------------
>
> Key: JCR-962
> URL: https://issues.apache.org/jira/browse/JCR-962
> Project: Jackrabbit
> Issue Type: Bug
> Components: core
> Reporter: Bertrand Delacretaz
> Attachments: 10-threads-dump.txt, 100-threads-dump.txt, JCR-962-ConcurrentVersioningWithTransactionsTest.patch
>
>
> Patch follows for a ConcurrentVersioningWithTransactionsTest, based on the existing ConcurrentVersioningTest but using transactions around the versioning operations.
> On my macbook, running the test with CONCURRENCY = 100 and NUM_OPERATIONS = 100 causes a deadlock after a few seconds, thread dumps follow.
> Note that I had to ignore StaleItemStateException (which is probably justified, due to not locking stuff IIUC) to let the threads run long enough to show the problem.
> Running the test a few times showed the same locking pattern several times: some threads are locked at line 87 (session.save(), no transaction) while others are at line 93 (transaction.commit()), in testConcurrentCheckinInTransaction():
> 80 public void testConcurrentCheckinInTransaction() throws RepositoryException {
> 81 runTask(new Task() {
> 82 public void execute(Session session, Node test) throws RepositoryException {
> 83 int i = 0;
> 84 try {
> 85 Node n = test.addNode("test");
> 86 n.addMixin(mixVersionable);
> 87 session.save();
> 88 for (i = 0; i < NUM_OPERATIONS / CONCURRENCY; i++) {
> 89 final UserTransaction utx = new UserTransactionImpl(test.getSession());
> 90 utx.begin();
> 91 n.checkout();
> 92 n.checkin();
> 93 utx.commit();
> 94 }
> 95 n.checkout();
> 96 } catch (Exception e) {
> 97 final String threadName = Thread.currentThread().getName();
> 98 final Throwable deepCause = getLevel2Cause(e);
> 99 if(deepCause!=null && deepCause instanceof StaleItemStateException) {
> 100 // ignore
> 101 } else {
> 102 throw new RepositoryException(threadName + ", i=" + i + ":" + e.getClass().getName(), e);
> 103 }
> 104 }
> 105 }
> 106 }, CONCURRENCY);
> 107 }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (JCR-962) Deadlocks in
ConcurrentVersioningWithTransactionsTest
Posted by "Marcel Reutegger (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Marcel Reutegger resolved JCR-962.
----------------------------------
Resolution: Fixed
Fix Version/s: 1.4
Assuming lazy consensus I committed the patch in revision: 551877
> Deadlocks in ConcurrentVersioningWithTransactionsTest
> -----------------------------------------------------
>
> Key: JCR-962
> URL: https://issues.apache.org/jira/browse/JCR-962
> Project: Jackrabbit
> Issue Type: Bug
> Components: core
> Reporter: Bertrand Delacretaz
> Fix For: 1.4
>
> Attachments: 10-threads-dump.txt, 100-threads-dump.txt, deadlocked-threads.txt, JCR-962-ConcurrentVersioningWithTransactionsTest.patch, JCR-962-fix.patch
>
>
> Patch follows for a ConcurrentVersioningWithTransactionsTest, based on the existing ConcurrentVersioningTest but using transactions around the versioning operations.
> On my macbook, running the test with CONCURRENCY = 100 and NUM_OPERATIONS = 100 causes a deadlock after a few seconds, thread dumps follow.
> Note that I had to ignore StaleItemStateException (which is probably justified, due to not locking stuff IIUC) to let the threads run long enough to show the problem.
> Running the test a few times showed the same locking pattern several times: some threads are locked at line 87 (session.save(), no transaction) while others are at line 93 (transaction.commit()), in testConcurrentCheckinInTransaction():
> 80 public void testConcurrentCheckinInTransaction() throws RepositoryException {
> 81 runTask(new Task() {
> 82 public void execute(Session session, Node test) throws RepositoryException {
> 83 int i = 0;
> 84 try {
> 85 Node n = test.addNode("test");
> 86 n.addMixin(mixVersionable);
> 87 session.save();
> 88 for (i = 0; i < NUM_OPERATIONS / CONCURRENCY; i++) {
> 89 final UserTransaction utx = new UserTransactionImpl(test.getSession());
> 90 utx.begin();
> 91 n.checkout();
> 92 n.checkin();
> 93 utx.commit();
> 94 }
> 95 n.checkout();
> 96 } catch (Exception e) {
> 97 final String threadName = Thread.currentThread().getName();
> 98 final Throwable deepCause = getLevel2Cause(e);
> 99 if(deepCause!=null && deepCause instanceof StaleItemStateException) {
> 100 // ignore
> 101 } else {
> 102 throw new RepositoryException(threadName + ", i=" + i + ":" + e.getClass().getName(), e);
> 103 }
> 104 }
> 105 }
> 106 }, CONCURRENCY);
> 107 }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-962) Deadlocks in
ConcurrentVersioningWithTransactionsTest
Posted by "Marcel Reutegger (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Marcel Reutegger updated JCR-962:
---------------------------------
Attachment: JCR-962-fix.patch
This patch replaces the internal XAResources on the XAWorkspace with two similar ones on the XAVersionManager. The idea is to lock the version manager early in the prepare phase and release the lock at the end of the transaction. When changes on the workspace are committed the version manager is already locked and stays locked until the version changes are committed.
If there are no version items in the transaction the write lock on the version manager is not acquired to allow concurrency between multiple sessions operating on different workspaces.
With this patch the sequence for locking workspace and version store is:
1) version store
2) workspace
The rest of the jackrabbit core should be reviewed and changed accordingly.
> Deadlocks in ConcurrentVersioningWithTransactionsTest
> -----------------------------------------------------
>
> Key: JCR-962
> URL: https://issues.apache.org/jira/browse/JCR-962
> Project: Jackrabbit
> Issue Type: Bug
> Components: core
> Reporter: Bertrand Delacretaz
> Attachments: 10-threads-dump.txt, 100-threads-dump.txt, deadlocked-threads.txt, JCR-962-ConcurrentVersioningWithTransactionsTest.patch, JCR-962-fix.patch
>
>
> Patch follows for a ConcurrentVersioningWithTransactionsTest, based on the existing ConcurrentVersioningTest but using transactions around the versioning operations.
> On my macbook, running the test with CONCURRENCY = 100 and NUM_OPERATIONS = 100 causes a deadlock after a few seconds, thread dumps follow.
> Note that I had to ignore StaleItemStateException (which is probably justified, due to not locking stuff IIUC) to let the threads run long enough to show the problem.
> Running the test a few times showed the same locking pattern several times: some threads are locked at line 87 (session.save(), no transaction) while others are at line 93 (transaction.commit()), in testConcurrentCheckinInTransaction():
> 80 public void testConcurrentCheckinInTransaction() throws RepositoryException {
> 81 runTask(new Task() {
> 82 public void execute(Session session, Node test) throws RepositoryException {
> 83 int i = 0;
> 84 try {
> 85 Node n = test.addNode("test");
> 86 n.addMixin(mixVersionable);
> 87 session.save();
> 88 for (i = 0; i < NUM_OPERATIONS / CONCURRENCY; i++) {
> 89 final UserTransaction utx = new UserTransactionImpl(test.getSession());
> 90 utx.begin();
> 91 n.checkout();
> 92 n.checkin();
> 93 utx.commit();
> 94 }
> 95 n.checkout();
> 96 } catch (Exception e) {
> 97 final String threadName = Thread.currentThread().getName();
> 98 final Throwable deepCause = getLevel2Cause(e);
> 99 if(deepCause!=null && deepCause instanceof StaleItemStateException) {
> 100 // ignore
> 101 } else {
> 102 throw new RepositoryException(threadName + ", i=" + i + ":" + e.getClass().getName(), e);
> 103 }
> 104 }
> 105 }
> 106 }, CONCURRENCY);
> 107 }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-962) Deadlocks in
ConcurrentVersioningWithTransactionsTest
Posted by "Marcel Reutegger (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Marcel Reutegger updated JCR-962:
---------------------------------
Attachment: deadlocked-threads.txt
Attached the stacktraces of the two relevant threads from 10-threads-dump.txt, which are in a deadlocked state.
> Deadlocks in ConcurrentVersioningWithTransactionsTest
> -----------------------------------------------------
>
> Key: JCR-962
> URL: https://issues.apache.org/jira/browse/JCR-962
> Project: Jackrabbit
> Issue Type: Bug
> Components: core
> Reporter: Bertrand Delacretaz
> Attachments: 10-threads-dump.txt, 100-threads-dump.txt, deadlocked-threads.txt, JCR-962-ConcurrentVersioningWithTransactionsTest.patch
>
>
> Patch follows for a ConcurrentVersioningWithTransactionsTest, based on the existing ConcurrentVersioningTest but using transactions around the versioning operations.
> On my macbook, running the test with CONCURRENCY = 100 and NUM_OPERATIONS = 100 causes a deadlock after a few seconds, thread dumps follow.
> Note that I had to ignore StaleItemStateException (which is probably justified, due to not locking stuff IIUC) to let the threads run long enough to show the problem.
> Running the test a few times showed the same locking pattern several times: some threads are locked at line 87 (session.save(), no transaction) while others are at line 93 (transaction.commit()), in testConcurrentCheckinInTransaction():
> 80 public void testConcurrentCheckinInTransaction() throws RepositoryException {
> 81 runTask(new Task() {
> 82 public void execute(Session session, Node test) throws RepositoryException {
> 83 int i = 0;
> 84 try {
> 85 Node n = test.addNode("test");
> 86 n.addMixin(mixVersionable);
> 87 session.save();
> 88 for (i = 0; i < NUM_OPERATIONS / CONCURRENCY; i++) {
> 89 final UserTransaction utx = new UserTransactionImpl(test.getSession());
> 90 utx.begin();
> 91 n.checkout();
> 92 n.checkin();
> 93 utx.commit();
> 94 }
> 95 n.checkout();
> 96 } catch (Exception e) {
> 97 final String threadName = Thread.currentThread().getName();
> 98 final Throwable deepCause = getLevel2Cause(e);
> 99 if(deepCause!=null && deepCause instanceof StaleItemStateException) {
> 100 // ignore
> 101 } else {
> 102 throw new RepositoryException(threadName + ", i=" + i + ":" + e.getClass().getName(), e);
> 103 }
> 104 }
> 105 }
> 106 }, CONCURRENCY);
> 107 }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-962) Deadlocks in
ConcurrentVersioningWithTransactionsTest
Posted by "Marcel Reutegger (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12508104 ]
Marcel Reutegger commented on JCR-962:
--------------------------------------
Added Bertrands' test case and created a new test suite, which contains all long running tests related to multi-threading: MultiThreadingTests. The suite will not run with the regression test while building jackrabbit-core but can easily be started in an IDE.
> Deadlocks in ConcurrentVersioningWithTransactionsTest
> -----------------------------------------------------
>
> Key: JCR-962
> URL: https://issues.apache.org/jira/browse/JCR-962
> Project: Jackrabbit
> Issue Type: Bug
> Components: core
> Reporter: Bertrand Delacretaz
> Attachments: 10-threads-dump.txt, 100-threads-dump.txt, deadlocked-threads.txt, JCR-962-ConcurrentVersioningWithTransactionsTest.patch
>
>
> Patch follows for a ConcurrentVersioningWithTransactionsTest, based on the existing ConcurrentVersioningTest but using transactions around the versioning operations.
> On my macbook, running the test with CONCURRENCY = 100 and NUM_OPERATIONS = 100 causes a deadlock after a few seconds, thread dumps follow.
> Note that I had to ignore StaleItemStateException (which is probably justified, due to not locking stuff IIUC) to let the threads run long enough to show the problem.
> Running the test a few times showed the same locking pattern several times: some threads are locked at line 87 (session.save(), no transaction) while others are at line 93 (transaction.commit()), in testConcurrentCheckinInTransaction():
> 80 public void testConcurrentCheckinInTransaction() throws RepositoryException {
> 81 runTask(new Task() {
> 82 public void execute(Session session, Node test) throws RepositoryException {
> 83 int i = 0;
> 84 try {
> 85 Node n = test.addNode("test");
> 86 n.addMixin(mixVersionable);
> 87 session.save();
> 88 for (i = 0; i < NUM_OPERATIONS / CONCURRENCY; i++) {
> 89 final UserTransaction utx = new UserTransactionImpl(test.getSession());
> 90 utx.begin();
> 91 n.checkout();
> 92 n.checkin();
> 93 utx.commit();
> 94 }
> 95 n.checkout();
> 96 } catch (Exception e) {
> 97 final String threadName = Thread.currentThread().getName();
> 98 final Throwable deepCause = getLevel2Cause(e);
> 99 if(deepCause!=null && deepCause instanceof StaleItemStateException) {
> 100 // ignore
> 101 } else {
> 102 throw new RepositoryException(threadName + ", i=" + i + ":" + e.getClass().getName(), e);
> 103 }
> 104 }
> 105 }
> 106 }, CONCURRENCY);
> 107 }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-962) Deadlocks in
ConcurrentVersioningWithTransactionsTest
Posted by "Bertrand Delacretaz (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Bertrand Delacretaz updated JCR-962:
------------------------------------
Attachment: 10-threads-dump.txt
Deadlocked threads dump with 10 concurrent tasks
> Deadlocks in ConcurrentVersioningWithTransactionsTest
> -----------------------------------------------------
>
> Key: JCR-962
> URL: https://issues.apache.org/jira/browse/JCR-962
> Project: Jackrabbit
> Issue Type: Bug
> Components: core
> Reporter: Bertrand Delacretaz
> Attachments: 10-threads-dump.txt, JCR-962-ConcurrentVersioningWithTransactionsTest.patch
>
>
> Patch follows for a ConcurrentVersioningWithTransactionsTest, based on the existing ConcurrentVersioningTest but using transactions around the versioning operations.
> On my macbook, running the test with CONCURRENCY = 100 and NUM_OPERATIONS = 100 causes a deadlock after a few seconds, thread dumps follow.
> Note that I had to ignore StaleItemStateException (which is probably justified, due to not locking stuff IIUC) to let the threads run long enough to show the problem.
> Running the test a few times showed the same locking pattern several times: some threads are locked at line 87 (session.save(), no transaction) while others are at line 93 (transaction.commit()), in testConcurrentCheckinInTransaction():
> 80 public void testConcurrentCheckinInTransaction() throws RepositoryException {
> 81 runTask(new Task() {
> 82 public void execute(Session session, Node test) throws RepositoryException {
> 83 int i = 0;
> 84 try {
> 85 Node n = test.addNode("test");
> 86 n.addMixin(mixVersionable);
> 87 session.save();
> 88 for (i = 0; i < NUM_OPERATIONS / CONCURRENCY; i++) {
> 89 final UserTransaction utx = new UserTransactionImpl(test.getSession());
> 90 utx.begin();
> 91 n.checkout();
> 92 n.checkin();
> 93 utx.commit();
> 94 }
> 95 n.checkout();
> 96 } catch (Exception e) {
> 97 final String threadName = Thread.currentThread().getName();
> 98 final Throwable deepCause = getLevel2Cause(e);
> 99 if(deepCause!=null && deepCause instanceof StaleItemStateException) {
> 100 // ignore
> 101 } else {
> 102 throw new RepositoryException(threadName + ", i=" + i + ":" + e.getClass().getName(), e);
> 103 }
> 104 }
> 105 }
> 106 }, CONCURRENCY);
> 107 }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.