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.
