jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marcel Reutegger (JIRA)" <j...@apache.org>
Subject [jira] Updated: (JCR-962) Deadlocks in ConcurrentVersioningWithTransactionsTest
Date Tue, 26 Jun 2007 08:45:26 GMT

     [ 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.


Mime
View raw message