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#a11813679 Sent from the Jackrabbit - Users mailing list archive at Nabble.com.
