jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Martijn Hendriks (JIRA)" <j...@apache.org>
Subject [jira] Commented: (JCR-721) Duplicate key in DatabasePersistenceManager
Date Wed, 14 Feb 2007 14:13:05 GMT

    [ https://issues.apache.org/jira/browse/JCR-721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12473102

Martijn Hendriks commented on JCR-721:

I think that I've traced a possible source of this error. It seems that the problem is at
least present when two threads try to add the same property to a node. 

For the reproduction of the issue I will attach a test class. Using this test class and a
debugger, the issue can be reproduced (In Jackrabbit 1.2.1) as follows:
1) set a breakpoint in the SharedItemStateManager in the Update.begin() method, for instance,
line 522.
2) start the test and resume it once so that the two threads from the test class are suspended.
3) resume one of the test threads (it will finish)
4) set a breakpoint in DatabasePersistenceManager.store @ line 274 ("super.store(changelog)");
5) resume the remaining thread: it will break in the DbPM.
6) stepping over the statement gives the exception (the itemstate has already been added by
the other thread).
7) stepping further it can be seen that the method store will never return, which is imho
a big issue...

So I guess that the problem is that if the ChangeLog objects that are given to the SISM Update
objects are non-disjoint, then persistence of one of them will fail because the DbPM.store
method will never return (because the super.store operation always fails).

It seems that this issue can be resolved by replacing "while(true)" by "while(trials>0)".
This, however, triggers a RepositoryException. Wouldn't it be nice to have a more specific
exception, such as a ConcurrentModificationException?


> Duplicate key in DatabasePersistenceManager
> -------------------------------------------
>                 Key: JCR-721
>                 URL: https://issues.apache.org/jira/browse/JCR-721
>             Project: Jackrabbit
>          Issue Type: Bug
>          Components: core
>    Affects Versions: 1.2.1
>         Environment: JackRabbit 1.2.1 using the default Derby repository.xml.
>            Reporter: Martijn Hendriks
> Hi,
> I ran into the exception pasted below. We had 2 threads that both were saving. Maybe
it is a race condition?  
> Regards,
> Martijn Hendriks
> <GX> creative online development B.V.
> t: 024 - 3888 261
> f: 024 - 3888 621
> e: martijnh@gx.nl
> Wijchenseweg 111
> 6538 SW Nijmegen
> http://www.gx.nl/ 
> Jan 26, 2007 2:23:36 PM org.apache.jackrabbit.core.persistence.db.DatabasePersistenceManager
> SEVERE: failed to write property state: e3847bad-f1ee-4adb-a109-e134900935b7/{http://gx.nl}edit_language
> ERROR 23505: The statement was aborted because it would have caused a duplicate key value
in a unique or primary key constraint or unique in dex identified by 'DEFAULT_PROP_IDX' defined
>         at org.apache.derby.iapi.error.StandardException.newException(Unknown Source)
>         at org.apache.derby.impl.sql.execute.IndexChanger.insertAndCheckDups(Unknown
>         at org.apache.derby.impl.sql.execute.IndexChanger.doInsert(Unknown Source)
>         at org.apache.derby.impl.sql.execute.IndexChanger.insert(Unknown Source)
>         at org.apache.derby.impl.sql.execute.IndexSetChanger.insert(Unknown Source)
>         at org.apache.derby.impl.sql.execute.RowChangerImpl.insertRow(Unknown Source)
>         at org.apache.derby.impl.sql.execute.InsertResultSet.normalInsertCore(Unknown
>         at org.apache.derby.impl.sql.execute.InsertResultSet.open(Unknown Source)
>         at org.apache.derby.impl.sql.GenericPreparedStatement.execute(Unknown Source)
>         at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(Unknown Source)
>         at org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeStatement(Unknown
>         at org.apache.derby.impl.jdbc.EmbedPreparedStatement.execute(Unknown Source)
>         at org.apache.jackrabbit.core.persistence.db.DatabasePersistenceManager.executeStmt(DatabasePersistenceManager.java:835)
>         at org.apache.jackrabbit.core.persistence.db.DatabasePersistenceManager.store(DatabasePersistenceManager.java:466)
>         at org.apache.jackrabbit.core.persistence.AbstractPersistenceManager.store(AbstractPersistenceManager.java:75)
>         at org.apache.jackrabbit.core.persistence.db.DatabasePersistenceManager.store(DatabasePersistenceManager.java:274)
>         at org.apache.jackrabbit.core.state.SharedItemStateManager$Update.end(SharedItemStateManager.java:675)
>         at org.apache.jackrabbit.core.state.SharedItemStateManager.update(SharedItemStateManager.java:808)
>         at org.apache.jackrabbit.core.state.LocalItemStateManager.update(LocalItemStateManager.java:326)
>         at org.apache.jackrabbit.core.state.XAItemStateManager.update(XAItemStateManager.java:313)
>         at org.apache.jackrabbit.core.state.LocalItemStateManager.update(LocalItemStateManager.java:302)
>         at org.apache.jackrabbit.core.state.SessionItemStateManager.update(SessionItemStateManager.java:295)
>         at org.apache.jackrabbit.core.ItemImpl.save(ItemImpl.java:1210)

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message