2
votes

I'm evaluating several NoSQL databases, including OrientDB. I'm a OrientDB newbie, trying to write a multi-threaded test that stresses OrientDB transactions.

Here is the code (imho too long to be included here): https://github.com/PeterKnego/nosql-benchmark/blob/master/orientdb/src/main/java/net/nosql_bench/OrientDbSimpleTransact.java

It's a simple standalone test that uses a number of parallel threads that read an entity, increases the value of number field and them save the entity, all inside a transaction.

It creates a lot of contention on one entity - that's the whole point. It kind of works, detects contention most of the time and properly rolls back the transaction.

I'm testing this on a locally installed OrientDB 2.0-rc2, client connects to it via a remote protocol.

Any ideas why sometimes transaction collisions get detected, while sometimes they pass?

1
Unfortunately it's not. The code uses transactions as described in docs. The problem is that sometimes it works and sometimes not.Peter Knego

1 Answers

1
votes

In your case I'd recommend using a connection pool. ThinkerPop API includes factory implementation for both, document and graph connections. Every time you create a new thread you should probably acquire an instance to the connection pool.

For documents you have

ODatabaseDocumentPool pool = new ODatabaseDocumentPool("plocal:/temp/mydb");
OrientGraph g = new OrientGraph(pool.acquire());

For graph database it is even simpler

OrientGraphFactory factory = new OrientGraphFactory("plocal:/temp/mydb").setupPool(1, 10);
OrientGraph txGraph = factory.getTx();

I'd try using a pooled connection to the database to see if this error persists, and remember to close the database instance once you have finished using it.

Check out this link http://orientdb.com/docs/2.0/orientdb.wiki/Graph-Factory.html