Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

Commit not saving transaction when multithreaded #1725

Closed
laa opened this Issue · 5 comments

1 participant

@laa
Collaborator
laa commented

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.

@laa laa was assigned
@laa
Collaborator
laa commented

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.

Remote
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.

Memory
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.

Local
Single threaded seems to work just fine, but multithreaded will fail on both inserts and deletes.

@laa
Collaborator
laa commented

Mike,
I have found the reason of this issue.
Will provide fix during 2 days.

@laa
Collaborator
laa commented

Mike,
Reason of this issue is old MVRBTree locking implementation , it will be fixed during two weeks #1604 , I am sorry that estimate was prolonged.

@laa
Collaborator

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.

@laa
Collaborator

Fixed for remote storage too. We need dmemory storage to fix this issue, memory storage can not support it. So I am closing it.

@laa laa closed this
@laa laa modified the milestone: 1.7, 2.0
@laa laa was assigned by lvca
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.