jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dominique Pfister" <dominique.pfis...@day.com>
Subject Re: DatabaseJournal doesn't work with springmodules
Date Tue, 24 Jul 2007 15:49:08 GMT
Hi Mike,

Please follow this link to find the issue:

  https://issues.apache.org/jira/browse/JCR-884

It should have been fixed in JR 1.3 and I therefore consider it very
strange that you still experience it! Does the MySQL log output
indicate that the _same_ JDBC connection inserts two records with the
same revision_id? Can you provide some simple test that causes this
failure in order to reproduce it?

Kind regards
Dominique

On 7/24/07, mike.wilson <mtw@fluent.com> wrote:
>
>
> Dominique Pfister wrote:
> >
> > Hi Rafał,
> >
> > a test case will probably not be necessary. Looks like the
> > DatabaseJournal does not save the returned revision_id along with the
> > record currently being created but rather as one of its instance
> > member variables and therefore incorrectly associates both records
> > with the same revision_id. The commit() call after having inserted
> > only the first of two records is another defect: apparently the
> > DatabaseJournal's lock is not truly reentrant. I will file a jira
> > issue for this.
> >
> > Thanks for reporting this bug!
> > Dominique
> >
>
> Greetings,
>
> I am experiencing what appear to be the same symptoms as reported by Rafal.
> Has a fix been made, or is there an open jira issue on this?  I could not
> find either, but could have missed it.  To summarize:
>
> FileJournal works perfectly
> DatabaseJournal (mysql/innodb/read-committed) fails with errors like:
>
> Caused by:
> com.mysql.jdbc.exceptions.MySQLIntegrityConstraintViolationException:
> Duplicate entry '46' for key 1
>         at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:931)
>         at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:2870)
>         at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:1573)
>         at
> com.mysql.jdbc.ServerPreparedStatement.serverExecute(ServerPreparedStatement.java:1160)
>         at
> com.mysql.jdbc.ServerPreparedStatement.executeInternal(ServerPreparedStatement.java:685)
>         at
> com.mysql.jdbc.PreparedStatement.execute(PreparedStatement.java:790)
>         at
> org.apache.jackrabbit.core.journal.DatabaseJournal.append(DatabaseJournal.java:293)
>
> I get the same result whenever I update a node, using any combination of the
> following:
> Jackrabbit-1.3 (release)
> Jackrabbit-1.3.1 (candidate release from
> http://people.apache.org/~jukka/jackrabbit/1.3.1)
> MySQL 5.0.27
> mysql-connector-5.0.3
> mysql-connector-5.0.7
>
> When I turn on logging in mysql, I see duplicate commits/inserts into the
> journal, the first containing the node data, the second containing some
> short (null?) value, both having the same JOURNAL_ID:
>
> 2 Query       SET autocommit=0
> 2 Query       update J_C_GLOBAL_REVISION set revision_id = revision_id + 1
> 2 Query       select revision_id from J_C_GLOBAL_REVISION
> 2 Query       select REVISION_ID, JOURNAL_ID, PRODUCER_ID, REVISION_DATA
> from J_C_JOURNAL where REVISION_ID > 44
> 4 Query       select 1 from DEMO_REFS where NODE_ID =
> '6b594e07-c26a-4f12-ba91-e7699f15df3e'
> 2 Query       SET autocommit=0
> 2 Query       update J_C_GLOBAL_REVISION set revision_id = revision_id + 1
> 2 Query       select revision_id from J_C_GLOBAL_REVISION
> 2 Query       select REVISION_ID, JOURNAL_ID, PRODUCER_ID, REVISION_DATA
> from J_C_JOURNAL where REVISION_ID > 44
> ...
> (SQL calls that update the node appear here)
> ...
> 4 Query       commit
> 2 Query       insert into J_C_JOURNAL(REVISION_ID, JOURNAL_ID, PRODUCER_ID,
> REVISION_DATA) values (46,'node3','JR',<lots of data for the node>)
> 2 Query       commit
> 2 Query       SET autocommit=1
> 2 Query       SET autocommit=1
> 2 Query       insert into J_C_JOURNAL(REVISION_ID, JOURNAL_ID, PRODUCER_ID,
> REVISION_DATA) values (46,'node3','JR',_binary'\0\0')
> 2 Query       SET autocommit=1
> 2 Query       SET autocommit=1
>
>
> Thanks!
> Mike Wilson
>
>
>
> On 3/28/07, Rafał Kwiecień <rafal@consol.pl> wrote:
> > Hi Dominique
> >
> > Dnia środa, 28 marca 2007 09:46, Dominique Pfister napisał:
> > > Hi Rafał,
> > >
> > > judging from the fact that the revision id is incremented twice and
> > > then applied to two different records, I ask myself whether these
> > > records are appended from the *same* thread in the *same* instance.
> > Yes - the same thread and the same instance of DatabaseJournal
> >
> > > When appending a record to the DatabaseJournal, the order of SQL calls
> > > is as follows:
> > >
> > > -- BEGIN TRANSACTION --
> > > UPDATE global_revision SET revision_id = revision_id + 1
> > > SELECT revision_id FROM global_revision
> > > INSERT INTO revision(revision_id, ...) VALUES (?,...)
> > > -- COMMIT --
> >
> > I my case it looks like:
> >
> > -- BEGIN TRANSACTION --
> > UPDATE global_revision SET revision_id = revision_id + 1
> > SELECT revision_id FROM global_revision
> > UPDATE global_revision SET revision_id = revision_id + 1
> > SELECT revision_id FROM global_revision
> > INSERT INTO revision(revision_id, ...) VALUES (?,...)
> > -- COMMIT --
> > INSERT INTO revision(revision_id, ...) VALUES (?,...)
> > -- COMMIT --
> >
> > >
> > > The first call is supposed to lock the global_revision table, the
> > > second will fetch the new revision_id and the last one will append a
> > > record with that new revision_id. If two instances would get the same
> > > revision_id, something would be seriously strange with the database
> > > transaction isolation. Two different threads in the same instance
> > > block each other until one has actually finished appending the new
> > > record. Therefore, the only conceivable scenario are  reentrant
> > > updates made by the same thread.
> >
> > After debugging I can say more about the problem. When transaction is
> > committed, there are methods prepare() and commit() called on
> > TransactionContext object. TransactionContext.resources contains five
> > objects: XAWorkspace, XAItemStateManager, XALockManager, XAVersionManager,
> > XAWorkspace. First TransactionContext.prepare() is called - and for each
> > resource prepare(). DatabaseJournal.doLock() is called twice (by
> > XAItemStateManager and XAVersionManager). When TransactionContext.commit()
> > is
> > called, also method commit() for each resource is called. And
> > DatabaseJournal.append() is called twice (also by XAItemStateManager and
> > XAVersionManager).
> >
> > >
> > > Can you reproduce your situation with a simple test case? This would
> > > definitely help...
> >
> > Sorry, I don't have simple test case. You can download spring-modules
> > package
> > and run jcr sample. If you add cluster configuration to
> > jackrabbit-repo.xml,
> > you get error.
> >
> >
> > --
> > Rafał Kwiecień
> > ConSol* Consulting & Solutions Software Poland Sp. z o.o.
> > ul. Piastowska 44C, 30-070 Kraków
> > http://www.consol.pl/
> >
>
>
>
> --
> View this message in context: http://www.nabble.com/DatabaseJournal-doesn%27t-work-with-springmodules-tf3452619.html#a11765520
> Sent from the Jackrabbit - Users mailing list archive at Nabble.com.
>
>
Mime
View raw message