OrientDB doesn't support *ThreadedTransactionalGraph* interface. If you
want to use it from multiple thread, then you should acquire a new
connection and release it every time. Example:
public class YourClass {
private OrientGraphFactory factory = new
OrientGraphFactory("plocal:/temp/mydb", "jayminer", "amigarocks");
public void exec(){
OrientGraph graph = factory.getTx();
try{
// USE THE GRAPH
} finally {
graph.shutdown();
}
}
}
For more information look at:
http://www.orientechnologies.com/docs/last/orientdb.wiki/Graph-Factory.html#graph-factory
.
Lvc@
On 28 October 2014 10:09, Xander Uiterlinden <[email protected]> wrote:
> Thanks for the explanation. When I use a separate graph instance of each
> of the threads it indeed works. I'm still wondering whether that complies
> with what is described in the Blueprints API documentation. The
> documentation for the ThreadedTransactionalGraph says:
>
> "While TransactionalGraph binds each transaction to the executing thread,
> ThreadedTransactionalGraph's newTransaction()
> <http://www.tinkerpop.com/docs/javadocs/blueprints/2.5.0/com/tinkerpop/blueprints/ThreadedTransactionalGraph.html#newTransaction()>
> returns
> a TransactionalGraph
> <http://www.tinkerpop.com/docs/javadocs/blueprints/2.5.0/com/tinkerpop/blueprints/TransactionalGraph.html>
> that
> represents its own transactional context independent of the executing
> thread. "
>
> While reading that I would not expect the TransactionalGraph to span it's
> transaction boundary across multiple threads.
> We're using OrientDB/Blueprints in a web application. Does this mean we're
> required to open a new graph instance for each request ? With the OrientDB
> 1.7 this was not necessary. Are there any performance implications to this ?
>
> Thanks,
>
> Xander
>
> On Monday, October 27, 2014 5:26:41 PM UTC+1, Lvc@ wrote:
>>
>> Hi Xander,
>> In OrientDB 1.7 the OrientGraph instance could be used across threads,
>> but starting from 2.0 each object must be used on own thread.
>>
>> Lvc@
>>
>>
>> On 27 October 2014 17:16, Andrey Lomakin <[email protected]> wrote:
>>
>>> Hi Xander,
>>> You should consider TransactionalGraph graph instance as connection and
>>> this connection should be thread local.
>>> But you have shared connection.
>>>
>>> On Mon, Oct 27, 2014 at 5:53 PM, Xander Uiterlinden <
>>> [email protected]> wrote:
>>>
>>>> Hi,
>>>>
>>>> I've been working on upgrading our graph code from OrientDB 1.7 to
>>>> OrientDB 2.0M2. Since we're using the blueprints API's this was quite easy,
>>>> however I noticed a difference regarding transactions with the new OrientDB
>>>> version.
>>>>
>>>> Using the TransactionalGraph API a transaction is supposed to be bound
>>>> to a thread, so commit() and rollback() invocations on different threads
>>>> should not have effect on each other. This appears not to be the case with
>>>> the new version.
>>>>
>>>> See the following code:
>>>>
>>>> final TransactionalGraph graph = m_graph.getGraph();
>>>>
>>>> Runnable r1 = new Runnable() {
>>>>
>>>> @Override
>>>> public void run() {
>>>> Vertex vertex = graph.addVertex(null);
>>>> System.out.println("add v1");
>>>> vertex.setProperty("name", "v1");
>>>> vertex.setProperty("category", "v");
>>>> // delay the commit to check whether the rollback on the other thread
>>>> has any effect on what we're doing here
>>>> try {
>>>> Thread.sleep(1000);
>>>> } catch (InterruptedException e) {
>>>> }
>>>> System.out.println("graph commit");
>>>> graph.commit();
>>>> }
>>>>
>>>> };
>>>>
>>>> // Thread 2 appears to roll-back the work that was done but not yet
>>>> committed in thread 1.
>>>> Runnable r2 = new Runnable() {
>>>>
>>>> @Override
>>>> public void run() {
>>>> try {
>>>> Thread.sleep(500);
>>>> } catch (InterruptedException e) {
>>>> }
>>>> System.out.println("graph rollback");
>>>> graph.rollback();
>>>> }
>>>> };
>>>>
>>>> new Thread(r1).start();
>>>> new Thread(r2).start();
>>>>
>>>> try {
>>>> Thread.sleep(1500);
>>>> }
>>>> catch (InterruptedException e) {
>>>> }
>>>> System.out.println("wake and check");
>>>> Iterable<Vertex> vertices = graph.getVertices("category", "v");
>>>> long count = StreamSupport.stream(vertices.spliterator(),
>>>> false).count();
>>>> assertEquals(1, count);
>>>>
>>>> To me this seems like a bug, or am I overlooking something ?
>>>>
>>>> Thanks,
>>>>
>>>> Xander
>>>>
>>>> --
>>>>
>>>> ---
>>>> You received this message because you are subscribed to the Google
>>>> Groups "OrientDB" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>> an email to [email protected].
>>>> For more options, visit https://groups.google.com/d/optout.
>>>>
>>>
>>>
>>>
>>> --
>>> Best regards,
>>> Andrey Lomakin.
>>>
>>> Orient Technologies
>>> the Company behind OrientDB
>>>
>>> --
>>>
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "OrientDB" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to [email protected].
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "OrientDB" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> For more options, visit https://groups.google.com/d/optout.
>
--
---
You received this message because you are subscribed to the Google Groups
"OrientDB" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
