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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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ń <[EMAIL PROTECTED]> 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. > >
