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.
