“Transaction was rolled back more times than it was started” Exception?

问题

I am running into this exception in a really odd place. Immediately after the first transaction on a fresh graph instance.

This is the static factory pseudocode:

if (factory == null){
    factory = new OrientGraphFactory("plocal:" + args[0] + File.separatorChar + "dir").setupPool(1, 10);
    factory.setAutoStartTx(false);
}
return new GRAPHWRAPPER(factory.getTx(), arg2, arg3, arg4, arg5);

inside the GRAPHWRAPPER class constructor I have the following:

begin TX,
add two vertices, 
commit TX <- Throws the exception

It only occurs on the second invocation of the factory. The invocations to the factory always happen inside the same thread (UI)

I am using 2.0.12/OS X 10.9/Java 7. What am I missing?

UPDATE:

I finally found an exception that makes more sense:

java.util.ConcurrentModificationException at java.util.LinkedHashMap$LinkedHashIterator.nextEntry(LinkedHashMap.java:394)
at java.util.LinkedHashMap$ValueIterator.next(LinkedHashMap.java:409) at com.orientechnologies.orient.core.tx.OTransactionRealAbstract.getNewRecordEntriesByClass(OTransactionRealAbstract.java:190)
at com.orientechnologies.orient.core.iterator.ORecordIteratorClass.config(ORecordIteratorClass.java:133)
at com.orientechnologies.orient.core.iterator.ORecordIteratorClass.<init>(ORecordIteratorClass.java:88)
at com.orientechnologies.orient.core.iterator.ORecordIteratorClass.<init>(ORecordIteratorClass.java:63)
at com.orientechnologies.orient.core.iterator.ORecordIteratorClass.<init>(ORecordIteratorClass.java:53)
at com.tinkerpop.blueprints.impls.orient.OrientElementScanIterable.iterator(OrientElementScanIterable.java:47)
at com.tinkerpop.blueprints.util.DefaultGraphQuery$DefaultGraphQueryIterable$1.<init>(DefaultGraphQuery.java:88)
at com.tinkerpop.blueprints.util.DefaultGraphQuery$DefaultGraphQueryIterable.iterator(DefaultGraphQuery.java:86) 
at com.tinkerpop.blueprints.impls.orient.OrientGraphQuery$OrientGraphQueryIterable.iterator(OrientGraphQuery.java:79)

This is inside the GRAPHWRAPPER constructor.

My code just uses the UI thread to instantiate the storage instances. Then all access is done by worker threads.

I have been printing out to console the activity and everyhting seems to match thread->graph pool instance. Each thread modifies its own set of elements. Like a subgraph per thread.

The only point in common I see is the two vertices added during share a key across threads. The values differ. I will change the logic to make the key unique per thread so orientdb does not include elements from another thread in the queries.

I will report status back later. It has been so random that creating a repeatable case is not possible.

UPDATE 2:

Making the key unique as described above solved several exceptions. In the process, I found two places where the ui thread uses the graph. These are probably the other culprits that trip the wire. I will change the logic and if I don't update again it is because it was userland error

来源：https://stackoverflow.com/questions/33194676/transaction-was-rolled-back-more-times-than-it-was-started-exception

标签

OrientDB