You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@jackrabbit.apache.org by "mike.wilson" <mt...@fluent.com> on 2007/07/24 17:21:06 UTC
Re: DatabaseJournal doesn't work with springmodules
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ń <ra...@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.
Re: DatabaseJournal doesn't work with springmodules
Posted by Dominique Pfister <do...@day.com>.
Hi Mike,
Sorry for the long delay, it must have skipped my attention! I will
verify the behaviour you described with the test cases you provided.
Kind regards
Dominique
On 8/9/07, mike.wilson <mt...@fluent.com> wrote:
>
> Hi,
>
> Just bumping this thread to see if anyone has had a chance to look at the
> test classes I posted. I'm still seeing double-inserts when using
> DatabaseJournal along with transactions. I've confirmed this behavior with
> released Jackrabbit 1.3.1. The test classes posted to this thread on 7/26
> should demonstrate the difference: DatabaseJournalTestNoTX.java (no
> transactions, no double-insert problem) and DatabaseJournalTestTX.java
> (transactions, double-insert problem.) Again, no problem using FileJournal
> with transactions on or off.
>
> Thanks!
> Mike Wilson
>
>
> mike.wilson wrote:
> >
> >
> > Dominique Pfister wrote:
> >>
> >> 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
> >>
> >
> > Hi Dominique,
> >
> > Thanks very much for the confirmation and link - I wrote a simple test
> > case, and using this, I traced the behavior I wrote about to using
> > DatabaseJournal in conjunction with transactions. I am still seeing
> > "double inserts" from the same JDBC connection (2 records inserted with
> > same revision ID) when using transactions. I do not get the
> > double-insert behavior in the normal test case without transactions.
> >
> > I have attached the two test cases (with and without transactions).
> > http://www.nabble.com/file/p11813679/DatabaseJournalTest.zip
> > DatabaseJournalTest.zip Am I doing something wrong with the transactions?
> >
> > Thanks again,
> > Mike Wilson
> >
> > On 7/24/07, mike.wilson <mt...@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ń <ra...@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.
> >>
> >>
> >
> >
>
>
>
> --
> View this message in context: http://www.nabble.com/DatabaseJournal-doesn%27t-work-with-springmodules-tf3452619.html#a12078871
> Sent from the Jackrabbit - Users mailing list archive at Nabble.com.
>
>
Re: DatabaseJournal doesn't work with springmodules
Posted by Dominique Pfister <do...@day.com>.
Hi,
very strange indeed: I could reproduce this error with the latest
release (1.3.1) and noticed that the source in that release does not
contain the fix applied in JCR-884. Apparently, this fix is only
available in the source trunk and has never made it into a release. I
will reopen it.
Thank you for pointing that out!
Kind regards
Dominique
On 09/08/07, mike.wilson <mt...@fluent.com> wrote:
>
> Hi,
>
> Just bumping this thread to see if anyone has had a chance to look at the
> test classes I posted. I'm still seeing double-inserts when using
> DatabaseJournal along with transactions. I've confirmed this behavior with
> released Jackrabbit 1.3.1. The test classes posted to this thread on 7/26
> should demonstrate the difference: DatabaseJournalTestNoTX.java (no
> transactions, no double-insert problem) and DatabaseJournalTestTX.java
> (transactions, double-insert problem.) Again, no problem using FileJournal
> with transactions on or off.
>
> Thanks!
> Mike Wilson
>
>
> mike.wilson wrote:
> >
> >
> > Dominique Pfister wrote:
> >>
> >> 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
> >>
> >
> > Hi Dominique,
> >
> > Thanks very much for the confirmation and link - I wrote a simple test
> > case, and using this, I traced the behavior I wrote about to using
> > DatabaseJournal in conjunction with transactions. I am still seeing
> > "double inserts" from the same JDBC connection (2 records inserted with
> > same revision ID) when using transactions. I do not get the
> > double-insert behavior in the normal test case without transactions.
> >
> > I have attached the two test cases (with and without transactions).
> > http://www.nabble.com/file/p11813679/DatabaseJournalTest.zip
> > DatabaseJournalTest.zip Am I doing something wrong with the transactions?
> >
> > Thanks again,
> > Mike Wilson
> >
> > On 7/24/07, mike.wilson <mt...@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ń <ra...@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.
> >>
> >>
> >
> >
>
>
>
> --
> View this message in context: http://www.nabble.com/DatabaseJournal-doesn%27t-work-with-springmodules-tf3452619.html#a12078871
> Sent from the Jackrabbit - Users mailing list archive at Nabble.com.
>
>
Re: DatabaseJournal doesn't work with springmodules
Posted by "mike.wilson" <mt...@fluent.com>.
Hi,
Just bumping this thread to see if anyone has had a chance to look at the
test classes I posted. I'm still seeing double-inserts when using
DatabaseJournal along with transactions. I've confirmed this behavior with
released Jackrabbit 1.3.1. The test classes posted to this thread on 7/26
should demonstrate the difference: DatabaseJournalTestNoTX.java (no
transactions, no double-insert problem) and DatabaseJournalTestTX.java
(transactions, double-insert problem.) Again, no problem using FileJournal
with transactions on or off.
Thanks!
Mike Wilson
mike.wilson wrote:
>
>
> Dominique Pfister wrote:
>>
>> 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
>>
>
> Hi Dominique,
>
> Thanks very much for the confirmation and link - I wrote a simple test
> case, and using this, I traced the behavior I wrote about to using
> DatabaseJournal in conjunction with transactions. I am still seeing
> "double inserts" from the same JDBC connection (2 records inserted with
> same revision ID) when using transactions. I do not get the
> double-insert behavior in the normal test case without transactions.
>
> I have attached the two test cases (with and without transactions).
> http://www.nabble.com/file/p11813679/DatabaseJournalTest.zip
> DatabaseJournalTest.zip Am I doing something wrong with the transactions?
>
> Thanks again,
> Mike Wilson
>
> On 7/24/07, mike.wilson <mt...@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ń <ra...@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.
>>
>>
>
>
--
View this message in context: http://www.nabble.com/DatabaseJournal-doesn%27t-work-with-springmodules-tf3452619.html#a12078871
Sent from the Jackrabbit - Users mailing list archive at Nabble.com.
Re: DatabaseJournal doesn't work with springmodules
Posted by "mike.wilson" <mt...@fluent.com>.
Dominique Pfister wrote:
>
> 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
>
Hi Dominique,
Thanks very much for the confirmation and link - I wrote a simple test case,
and using this, I traced the behavior I wrote about to using DatabaseJournal
in conjunction with transactions. I am still seeing "double inserts" from
the same JDBC connection (2 records inserted with same revision ID) when
using transactions. I do not get the double-insert behavior in the normal
test case without transactions.
I have attached the two test cases (with and without transactions).
http://www.nabble.com/file/p11813679/DatabaseJournalTest.zip
DatabaseJournalTest.zip Am I doing something wrong with the transactions?
Thanks again,
Mike Wilson
On 7/24/07, mike.wilson <mt...@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ń <ra...@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.
>
>
--
View this message in context: http://www.nabble.com/DatabaseJournal-doesn%27t-work-with-springmodules-tf3452619.html#a11813679
Sent from the Jackrabbit - Users mailing list archive at Nabble.com.
Re: DatabaseJournal doesn't work with springmodules
Posted by Dominique Pfister <do...@day.com>.
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 <mt...@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ń <ra...@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.
>
>