Bugs item #2810319, was opened at 2009-06-22 10:54 Message generated for change (Comment added) made by mwaschkowski You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=713730&aid=2810319&group_id=129076
Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Query Execution Group: Sedna (current) Status: Open Resolution: Accepted Priority: 5 Private: No Submitted By: mwaschkowski (mwaschkowski) Assigned to: Ivan Shcheklein (shcheklein) Summary: FATAL Data Inconsistency Initial Comment: Keep getting FATAL 22/06/2009 09:56:04 (TRN test pid=7664 sid=49 trid=49) [micro.cpp:thirdElementAndTextInsertProcedure:90]: Data Inconsistency errors. ---------------------------------------------------------------------- Comment By: mwaschkowski (mwaschkowski) Date: 2009-06-26 13:11 Message: Can you clarify the autocommit behavior? You said you could reproduce when autocommit == off Then you said 'if you really need', set autocommit == off I think you meant to see that if I do need that behavior, set autocommit==on? According to docs: 'The Java API does not provide auto-commit mode for transactions. That is, every transaction must be explicitly started (by means of begin) and commited (by means of commit). If session is closed (by means of close) before a transaction committed, server does rollback for that transaction, and close throws DriverException.' If there is a way to setup auto-commit on via Java, then the docs need updating. Actually, its not strange at all. This is a common approach for doing persistence testing - just rollback everything after each test case, see: http://static.springframework.org/spring/docs/1.2.x/reference/testing.html#d0e15735 ---------------------------------------------------------------------- Comment By: Ivan Shcheklein (shcheklein) Date: 2009-06-26 11:51 Message: I was able to reproduce this when autocommit mode is turned off. We will fix this as soon as possible. BTW, turn off autocommit if you really need this! It's quite strange to see CREATE "Contacts", DROP "Contacts" and LOAD into "Contacts" statements within one transaction. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2009-06-24 11:04 Message: My own API, using the standard DAO pattern. The code is simply saving the same document, twice. The first time that the document saves, a UUID is assigned, and the document is loaded into the system via: statement.loadDocument(xml, persistable.getUuid(), collectionName); The second time the document is saved, it has a UUID assigned and the update replace statement is used instead. ---------------------------------------------------------------------- Comment By: Ivan Shcheklein (shcheklein) Date: 2009-06-24 10:57 Message: I don't understand, actually. What API do you use? XML:DB API? If code is so simple, what the thing like: UPDATE replace $doc in document("589d65ff-081b-47ac-8748-4ccd6678d1cb", "docs")/root with <com.circumail.server.sedna.DocumentImpl> <uuid>589d65ff-081b-47ac-8748-4ccd6678d1cb</uuid> <xml><foo><bar>1245354990296</bar></foo></xml> </com.circumail.server.sedna.DocumentImpl> does mean? ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2009-06-24 10:46 Message: There was no data in the system to being with, the code is dead simple: Persistable doc = new Document("<foo><bar>" + System.currentTimeMillis() + "</bar></foo>"); documentDao.save(doc, docCollectionName); documentDao.save(doc, docCollectionName); SessionPerThreadSedna.getConnection().commit(); Unfortunately I haven't been able to make a reproduceable test case for any of the faults yet, although I did try. ---------------------------------------------------------------------- Comment By: Ivan Shcheklein (shcheklein) Date: 2009-06-22 11:31 Message: For the first time this fault was caused by the following sequence of queries: CREATE COLLECTION 'docs' LOAD STDIN "589d65ff-081b-47ac-8748-4ccd6678d1cb" "docs" UPDATE replace $doc in document("589d65ff-081b-47ac-8748-4ccd6678d1cb", "docs")/root with <com.circumail.server.sedna.DocumentImpl> <uuid>589d65ff-081b-47ac-8748-4ccd6678d1cb</uuid> <xml><foo><bar>1245354990296</bar></foo></xml> </com.circumail.server.sedna.DocumentImpl> document('589d65ff-081b-47ac-8748-4ccd6678d1cb', 'docs') Can you give me a data (in private, if you can't share) on which this sequence of queries was executed? Can you determine a stable way to reproduce this fault on the clean data base? ---------------------------------------------------------------------- Comment By: mwaschkowski (mwaschkowski) Date: 2009-06-22 11:00 Message: Windows XP Home, SP3 ---------------------------------------------------------------------- Comment By: mwaschkowski (mwaschkowski) Date: 2009-06-22 10:57 Message: Sedna version: sedna-3.1.175 was running a simple xquery: collection("Contacts")/node() ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=713730&aid=2810319&group_id=129076 ------------------------------------------------------------------------------ _______________________________________________ Sedna-discussion mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/sedna-discussion
