Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Commit not saving transaction when multithreaded #1725

Closed
andrii0lomakin opened this issue Oct 2, 2013 · 5 comments
Closed

Commit not saving transaction when multithreaded #1725

andrii0lomakin opened this issue Oct 2, 2013 · 5 comments
Assignees
Milestone

Comments

@andrii0lomakin
Copy link
Member

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.

@ghost ghost assigned andrii0lomakin Oct 2, 2013
@andrii0lomakin
Copy link
Member Author

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.

@andrii0lomakin
Copy link
Member Author

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

@andrii0lomakin
Copy link
Member Author

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.

@andrii0lomakin
Copy link
Member Author

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.

@andrii0lomakin
Copy link
Member Author

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

@andrii0lomakin andrii0lomakin modified the milestones: 1.7, 2.0 Mar 26, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

1 participant