Hi,
Thanks a lot for the clarification, Anil.
Actually that was our first understanding, so we did it, we set the system
property on the server side (using the
*--J=-Dgemfire.detectReadConflicts=true* argument for *gfsh start server*),
but we didn't observe any effect: the isolation problems keeps happening.
Then reading a little bit more about it in the docs, and checking this
question
<https://markmail.org/message/yssxqfs5jbapqklz?q=detectReadConflicts+order:date-backward&page=2>
on the mailing lists, which includes some code to set the system property,
we understood (apparently wrongly) that it was something to be done at
client side.
So, as I mentioned, setting the property on the server side, and doing our
reading operations inside a transaction, we don't observe any effect: no
CommitConflictException thrown in the C++ app, and we keep observing the
isolation issue. Are we doing something wrong?, or maybe is the
geode-native not properly propagating the exception to the caller?
Thanks a lot in advance.
Kind regards,

Aníbal.


On Tue, Sep 25, 2018 at 12:39 AM Anilkumar Gingade <[email protected]>
wrote:

> The transaction semantics are maintained/managed at server side. You need
> to set this system property on the server side.
>
> -Anil.
>
>
> On Mon, Sep 24, 2018 at 2:31 PM Anibal Caceres Hernando <
> [email protected]> wrote:
>
>> Hi,
>>
>> We are writing a C++ application interacting with geode, using for it the
>> geode-native. We are using the pre-modernization version of geode-native.
>>
>> We are experiencing the transactions isolation issue described in the
>> Geode documentation (
>> http://geode.apache.org/docs/guide/16/developing/transactions/transaction_semantics.html),
>> and would like to know how to deal with it from our C++ code. Our
>> understanding is that in order to avoid the dirty reads we have to
>> configure the gemfire.detectReadConflicts to true in our application, but
>> we don't see how to do so with geode native. Is it possible to do so?, can
>> we avoid isolation in our C++ application that way?
>>
>> Thanks a lot in advance.
>>
>> Kind regards,
>>
>>
>>
>> Aníbal.
>>
>

Reply via email to