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

Concurrent access fails various ways and performance is bad [moved] #115

Closed
lvca opened this issue Dec 10, 2012 · 0 comments
Closed

Concurrent access fails various ways and performance is bad [moved] #115

lvca opened this issue Dec 10, 2012 · 0 comments

Comments

@lvca
Copy link
Member

lvca commented Dec 10, 2012

This is Issue 115 moved from a Google Code project.
Added by 2010-09-18T08:56:55.000Z by jani.laa...@gmail.com.
Please review that bug for more context and additional comments, but update this bug.
Closed (Done).

Original labels: Type-Defect, Priority-Medium, v0.9.23

Original description

I am having serious trouble accessing local database with multiple concurrent threads. Suspecting there exists serious thread safety issues that need to be fixed asap.

Using trunk @ 1414

Here are some of the issues I've seen so far..


1) Transactions are not consistent.

I have a transaction in which I save 1000 objects of class A and 1000 objects of class B but after succesful saves and commit I get different number of type A and B objects.

Here's an example run with my example code using THREAD_COUNT = 2:
Thread[main,5,main]: Creating new database
Thread[Thread-2,5,main]: THREAD START
Thread[Thread-4,5,main]: THREAD START
Thread[Thread-2,5,main]: internal=22, index=0, default=0, orole=3, ouser=3, person=1204, company=1000, 
Thread[Thread-2,5,main]: THREAD END
Thread[Thread-4,5,main]: COMMIT FAILED 100 TIMES
Thread[Thread-4,5,main]: internal=22, index=0, default=0, orole=3, ouser=3, person=1204, company=1000, 
Thread[Thread-4,5,main]: THREAD END
Thread[main,5,main]: All db write test threads finished
Thread[main,5,main]: internal=22, index=0, default=0, orole=3, ouser=3, person=1204, company=1000, 

NOTE: Issue is that it's impossible for person count to be something different than company count. Even if commit fails, it stores 204(?) person objects but not a single company objects.


2) Acquiring connection from ODatabaseObjectPool.global().acquire throws four different exceptions

Acquire throws "randomly" these:
com.orientechnologies.orient.core.exception.OStorageException: Error in creation of new cluster 'company' of type: LOGICAL
or
com.orientechnologies.common.concur.lock.OLockException: Error on creation of the new resource in the pool
or
com.orientechnologies.orient.core.exception.OCommandExecutionException: Error on execution of command: OSQLQuery [text=select from OUser where name = 'admin']
Caused by: java.lang.NumberFormatException: For input string: "2ORole"
or
com.orientechnologies.common.concur.lock.OLockException: Can't acquire lock on requested resource: local:/tmp/orient-database-test/foo

3) ODatabaseObjectTx.save is erratic throws two different exceptions

save sometimes throws these:
com.orientechnologies.orient.core.exception.OStorageException: Error in creation of new cluster 'company' of type: LOGICAL
or
java.util.ConcurrentModificationException


4) "Recovery of pending transactions" during connection acquire is logged even though I'm sure I have closed all resources properly and even rollbacked failed transactions

[OTxSegment] Started the recovering of pending transactions after a brute shutdown. Found 4736 entry logs. Scanning...


5) Performance is very bad (hangs?) during concurrent database access

I have ten concurrent threads simply storing 1000 class A and 1000 class B objects and then performing simple count query. I cannot find the way to perform this reliably. No matter which TXTYPE I choose and try to retry failed commits.  When I perform tiny Thread.sleep after failed commit, it seems my program won't finish ever.

In any case having commit to throw because db is "busy" is quite akward resolution, I cannot seen to find out the right way to cope this.



I've attached my source code here. Using Xmx1024M and Xms1024M. It's simple and short but a bit hard to read on some places because I've tried to do the best to housekeep everything right and be gentle when errors occur.


Best of luck resolving these issues, I truly hope this product matures quickly, because the values in OrientDB match my need brilliantly. Thank you for the effort so far!
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