Hi Odysseas,

Could you provide information which I asked in issue ?


On Thu, Jun 5, 2014 at 8:34 PM, Odysseas <[email protected]> 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].
> 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.

Reply via email to