We're running into an issue where a commit is not saving the transaction to the database. We're mainly testing against an in memory database, but this issue can be replicated against a remote database. I updated this morning to the latest 1.6.0-SNAPSHOT dated 9/30/13, though we can also reproduce this issue in 1.5.1.
We've written a TestCase with three tests (https://gist.github.com/mikeosterlie/0d41249e46c9e7205ac9); testWithTransaction() should fail fairly quickly with an AssertionException "Insert issue: expected record #11:-3 was not found in database." Every now and then it might reference a Delete, but it's mostly an Insert.
The commit() does not throw an exception, but the RIDs in the records in the transaction are not updated to swap out the temporary RIDs and a query against the database does not show the record in the database at all. We do also see this issue, though much more rarely, with deletes not actually removing the record from the database after a commit.
If we comment out any transaction code in our main code the exact same logic work flawlessly, so I don't believe it's a logic error on our part. Single threaded seems to work just fine, though we are looking into a possible replication of the issue in single threaded mode against a remote database.
Ok, we've done a bit more digging into this and found that all three connection types (remote, memory, and local) have issues with transactions. I'll try to detail them here. We're working on expanding our test case to better show the issues. For all three types running the same code without transactions results in no errors at all.
I should note that in all cases commit() does not throw an Exception nor give any indication that something bad has happened.
On a commit the record is updated in the database, but the ORID object returned by getIdentity() after a save() does not get updated to hold the new RID; it's still the temporary negative RID. We can verify this because the database holds all the records that we expect, but our client side cache of ORIDs contains negative numbers for those newly inserted records after a commit.
This issue happens on both single and multithreaded runs. We did not see any issue with deletes.
A single threaded memory database works with no issues. However, when running multithreaded the record is not even saved in the database. The ORID object maintains the negative number, and the record we expect to find in the database is not there.
Delete will fail to remove a record as well.
Single threaded seems to work just fine, but multithreaded will fail on both inserts and deletes.
I have found the reason of this issue.
Will provide fix during 2 days.
Reason of this issue is old MVRBTree locking implementation , it will be fixed during two weeks #1604 , I am sorry that estimate was prolonged.
Fixed for plocal in https://github.com/orientechnologies/blueprints/compare/rid-bag-migration will be integrated in main branch and fixed for remote during 10 days.
Fixed for remote storage too. We need dmemory storage to fix this issue, memory storage can not support it. So I am closing it.