Hi Andrey, Sorry for the delay in my response. It is difficult to extract a test case from our application for this scenario. My goal when I reported the issue was not to file a bug report but rather to understand what is the expected behavior and if what we are experiencing is the correct behavior.
By changing the code to force the commit, the application is working properly. I looked through the OrientDB source code and stepped through some of the code and found that the counter of transactions is incremented in the begin operation which we never explicitly invoke. It wasn't clear though what the counter is counting. It seems that it is counting the number of nested transactions but we execute all the operations that should be committed when the commit method is invoked within one thread and we never invoke begin explicitly so, why were our transactions considered to be nested (why was the count greater than 1 causing the commit not to commit)? I was suspecting that maybe connections from the pool may not have had their count decremented to zero after being released by the previous thread so when the begin in invoked on the current thread, the operation is treated as a nested transaction, but I haven't had the time to explore this hypothesis. Thanks, Odysseas On Friday, June 13, 2014 1:59:20 AM UTC-4, Andrey Lomakin wrote: > > Hi Odysseas, > Could you provide additional information which I asked in > https://github.com/orientechnologies/orientdb/issues/2435 issue ? > > > On Tue, Jun 10, 2014 at 7:22 PM, Andrey Lomakin <[email protected] > <javascript:>> wrote: > >> Hi Odysseas, >> >> Could you provide information which I asked in issue ? >> >> >> On Thu, Jun 5, 2014 at 8:34 PM, Odysseas <[email protected] >> <javascript:>> wrote: >> >>> Hi Andrey, >>> No, we do not invoke tx.begin() before performing any operations using >>> connections from the pool. I will open a case for this. >>> Thanks, >>> odysseas >>> >>> >>> On Thursday, June 5, 2014 11:18:57 AM UTC-4, Andrey Lomakin wrote: >>> >>>> Hi Odysseas, >>>> One question do you directly call tx.begin() before operation ? >>>> >>>> Any way it is not convenient to track whether you call begin or not, so >>>> could you open issue about this case ? >>>> >>>> >>>> On Tue, Jun 3, 2014 at 12:57 PM, Odysseas <[email protected]> wrote: >>>> >>>>> Hi Andrey, >>>>> We are now using the 1.7 release. >>>>> >>>>> >>>>> On Tuesday, June 3, 2014 1:07:53 AM UTC-4, Andrey Lomakin wrote: >>>>> >>>>>> 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. >>>>> >>>> >>>> >>>> >>>> -- >>>> 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] <javascript:>. >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> >> >> -- >> Best regards, >> Andrey Lomakin. >> >> Orient Technologies >> the Company behind OrientDB >> >> > > > -- > 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.
