Hi Odysseas, Give me couple of days I will look on your question/issue. Which version do you use btw ?
On Tue, Jun 3, 2014 at 3:03 AM, Odysseas <[email protected]> wrote: > > I have run into a situation where after a commit and a close of a > connection from the graph connection pool, the changes made to the graph > within that > transaction are not committed into the database. I traced through the code > and it looks like the OTransactionOptimistic class is keeping track of a > counter > of what it considers to be nested transactions (txStartCounter) and if the > counter is greater than 1 during a commit, the commit is not performed. I > was able > to resolve the issue by forcing the transaction to commit. > > My question is given that the transaction is started automatically when we > obtain the connection from the pool and we never explicitly invoke a begin > transaction operation on the connection, when does the counter get > incremented? I would expect that when we close the connection that the > transaction > would automatically be committed to the database if any previous commit > operations were postponed due to nesting of multiple transaction but that is > not happening. The connection is closed and the transaction is not > committed unless we force the commit to happen. > > Thanks, > Odysseas > > -- > > --- > 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.
