You should let the DB close g.shutdown(true, false), otherwise it won't be returned to pool. Or you should not call shutdown() whatsoever.
If you want to make your methods usable per se (so that they will take care of releasing db) and simultaneously usable within other methods, you would have to create similar mechanism as transaction propagation, but with getGraph() and shutdown() methods instead of begin() and commit(), so that only the outermost shutdown() call will actually call g.shutdown(): GraphProducer::getGraph() would obtain instance from pool when counter == 0, otherwise it would increment the counter and return the already obtained instance. GraphProducer::shutdown() would call shutdown() on graph instance when counter == 0, otherwise it would just decrement the counter. Dne středa 30. září 2015 20:58:46 UTC+2 Tai Hu napsal(a): > > Thanks Jan for pointing me to the right direction. I fixed this issue by > calling g.shutdown(false, false) in all my lookup methods. Then it won't > commit the transaction. > > On Wednesday, September 30, 2015 at 2:37:39 PM UTC-4, Jan Plaček wrote: >> >> Yes, shutdown commits transaction, the transaction is tied to a graph >> instance and graph instance to current thread. You can't span tx across >> multiple graph instances or threads (for example multiple requests) >> >> Dne středa 30. září 2015 20:30:12 UTC+2 Tai Hu napsal(a): >>> >>> Jan, >>> I figured out what the the problem is. It is because during the >>> delete, I also do a lot of lookup to find related vertices to delete. For >>> those lookup, I called GraphFactory().getGraph() to have a new graph >>> instance from the pool and at the end of lookup, I called g.shutdown() to >>> return it to the pool. It seems that that g.shutdown() commits all >>> transaction. >>> >>> Tai >>> >>> On Wednesday, September 30, 2015 at 1:52:36 PM UTC-4, Jan Plaček wrote: >>>> >>>> You have to start each transaction even the nested ones ... when you >>>> start a transaction by begin() and there is already a running transaction, >>>> than begin() will just increment that counter. Similary when you call >>>> commit() the counter is decremented and actual commit is performed only >>>> when the counter is zero (this means this is the outermost commit). This >>>> is >>>> how TX keeps track of nested transaction to make propagation work. The >>>> number of begin() calls have to be the same as the number of commit() >>>> calls. >>>> >>>> Dne středa 30. září 2015 19:41:07 UTC+2 Tai Hu napsal(a): >>>>> >>>>> I just tried to dump out that number in each my delete method. It >>>>> turns out this number is always 0. What does that mean? I only called >>>>> begin() once in the top level method never called it again in each delete >>>>> method. >>>>> >>>>> Thanks, >>>>> >>>>> Tai >>>>> >>>>> On Wednesday, September 30, 2015 at 12:15:19 PM UTC-4, Jan Plaček >>>>> wrote: >>>>>> >>>>>> Try to dump following in your methods: >>>>>> >>>>>> graph.getRawGraph().getTransaction().amountOfNestedTxs(); >>>>>> >>>>>> I checked the tx implementation, and commit is not triggered when >>>>>> this number is not 0: >>>>>> >>>>>> >>>>>> https://github.com/orientechnologies/orientdb/blob/16cffc1b9ac9553f4ec4b1af8caa6a41a0322697/core/src/main/java/com/orientechnologies/orient/core/tx/OTransactionOptimistic.java >>>>>> >>>>>> Maybe retarded question, but just to be sure, do you also call >>>>>> begin() in deleteChild(g) and deleteParent(g) ? >>>>>> >>>>>> Dne úterý 29. září 2015 20:59:52 UTC+2 Tai Hu napsal(a): >>>>>>> >>>>>>> I have a question regarding to transaction propagation. For my data >>>>>>> model, I have bunch of delete methods to delete each individual type of >>>>>>> vertex in OrientDB. However, I also have a big delete method which >>>>>>> suppose >>>>>>> to delete all types of object at once. This operation need to be ACID, >>>>>>> either delete all of them or not at all. I created one OrientGraph >>>>>>> object >>>>>>> and pass it into all each individual methods. However, after each >>>>>>> delete >>>>>>> method, the operation is automatically commit. So if my big delete >>>>>>> method >>>>>>> failed half way, my OrientDB will be out of sync. I tried to call >>>>>>> setAutoStartTx(false) on OrientGraph and manually called begin() method >>>>>>> on >>>>>>> OrientGraph, but transaction still automatically committed after each >>>>>>> delete method. Is there any way to manually control my transaction in >>>>>>> OrientGraph? >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Tai >>>>>>> >>>>>> -- --- 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.
