You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@geode.apache.org by Anibal Caceres Hernando <an...@gmail.com> on 2018/09/24 21:31:36 UTC
Doubts about dealing with transactions isolation from geode-native
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.
Re: Doubts about dealing with transactions isolation from geode-native
Posted by Anibal Caceres Hernando <an...@gmail.com>.
Hi all,
We have finally solved this, and it is working properly. Our problem was
that we were capturing the CommitConflictException in the reads operations,
and it must be done in the commit. Capturing it in the commit, the
isolation is detected by geode, the exception is thrown in our C++
application and we can capture it.
Thank you very much for your support.
Kind regards,
Aníbal.
On Wed, Sep 26, 2018 at 9:03 AM Anibal Caceres Hernando <
anibal.caceres@gmail.com> wrote:
> Hi,
> Yes, that's it: Subscribers_meta has same keys as Subscriber, and
> Sessions_meta has same keys as Sessions.
> Kind regards,
>
> Aníbal.
>
>
> On Wed, Sep 26, 2018 at 12:04 AM Real Wes <Th...@outlook.com> wrote:
>
>> And Subscribers_meta has the exact same key as Subscribers and
>> Sessions_meta has the exact same key as Sessions?
>>
>> Wes
>>
>> On Sep 25, 2018, at 5:50 PM, Anibal Caceres Hernando <
>> anibal.caceres@gmail.com> wrote:
>>
>> Hi Jake,
>> Following are server-cache.xml, and client-cache.xml, please, let me know
>> if you need more info. You'll see partitioned regions, but we have observed
>> the issue also with replicated ones.
>> Kind regards,
>>
>> Aníbal.
>>
>> -------------- server-cache.xml --------------
>>
>> <?xml version="1.0" encoding="UTF-8"?>
>>
>> <cache xmlns="http://geode.apache.org/schema/cache"
>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>> xsi:schemaLocation="http://geode.apache.org/schema/cache
>> http://geode.apache.org/schema/cache/cache-1.0.xsd"
>> version="1.0"
>> copy-on-read="true">
>>
>> <!-- Topology information fragment -->
>> <region-attributes id="provisioned-data"
>> refid="PARTITION" />
>>
>> <!-- Physical data model fragment -->
>> <region name="Subscribers" refid="provisioned-data">
>> </region>
>>
>> <region name="Sessions" refid="provisioned-data">
>> </region>
>>
>> <region name="Subscribers_meta" refid="provisioned-data">
>> <region-attributes>
>> <partition-attributes colocated-with="Subscribers" />
>> </region-attributes>
>> </region>
>>
>> <region name="Sessions_meta" refid="provisioned-data">
>> <region-attributes>
>> <partition-attributes colocated-with="Sessions" />
>> </region-attributes>
>> </region>
>> </cache>
>>
>> -------------- client-cache.xml --------------
>>
>> <?xml version="1.0" encoding="UTF-8"?>
>> <client-cache xmlns="http://geode.apache.org/schema/cache"
>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>> xsi:schemaLocation="
>> http://geode.apache.org/schema/cache
>> http://geode.apache.org/schema/cache/cache-1.0.xsd"
>> version="1.0"
>> copy-on-read="true" >
>> <!-- ======= [ Deployment specific fragment ] ======== -->
>> <pool name="provision-server-pool" subscription-enabled="true" >
>> <locator host="dms-locator"
>> port="10334" />
>> </pool>
>>
>> <!-- ======= [ PDM specific fragment ] ========== -->
>> <region name="Subscribers">
>> <region-attributes refid="PROXY"
>> pool-name="provision-server-pool" />
>> </region>
>> <region name="Sessions">
>> <region-attributes refid="PROXY"
>> pool-name="provision-server-pool" />
>> </region>
>> <region name="Subscribers_meta">
>> <region-attributes refid="PROXY"
>> pool-name="provision-server-pool"/>
>> </region>
>> <region name="Sessions_meta">
>> <region-attributes refid="PROXY"
>> pool-name="provision-server-pool"/>
>> </region>
>>
>> </client-cache>
>>
>>
>>
>> On Tue, Sep 25, 2018 at 3:39 PM Jacob Barrett <jb...@pivotal.io>
>> wrote:
>>
>>> Can you provide details on your server configuration, region
>>> configuration, and client configuration?
>>>
>>> -Jake
>>>
>>>
>>> On Sep 24, 2018, at 11:01 PM, Anibal Caceres Hernando <
>>> anibal.caceres@gmail.com> wrote:
>>>
>>> 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 <ag...@pivotal.io>
>>> 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 <
>>>> anibal.caceres@gmail.com> 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.
>>>>>
>>>>
>>
Re: Doubts about dealing with transactions isolation from geode-native
Posted by Anibal Caceres Hernando <an...@gmail.com>.
Hi,
Yes, that's it: Subscribers_meta has same keys as Subscriber, and
Sessions_meta has same keys as Sessions.
Kind regards,
Aníbal.
On Wed, Sep 26, 2018 at 12:04 AM Real Wes <Th...@outlook.com> wrote:
> And Subscribers_meta has the exact same key as Subscribers and
> Sessions_meta has the exact same key as Sessions?
>
> Wes
>
> On Sep 25, 2018, at 5:50 PM, Anibal Caceres Hernando <
> anibal.caceres@gmail.com> wrote:
>
> Hi Jake,
> Following are server-cache.xml, and client-cache.xml, please, let me know
> if you need more info. You'll see partitioned regions, but we have observed
> the issue also with replicated ones.
> Kind regards,
>
> Aníbal.
>
> -------------- server-cache.xml --------------
>
> <?xml version="1.0" encoding="UTF-8"?>
>
> <cache xmlns="http://geode.apache.org/schema/cache"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xsi:schemaLocation="http://geode.apache.org/schema/cache
> http://geode.apache.org/schema/cache/cache-1.0.xsd"
> version="1.0"
> copy-on-read="true">
>
> <!-- Topology information fragment -->
> <region-attributes id="provisioned-data"
> refid="PARTITION" />
>
> <!-- Physical data model fragment -->
> <region name="Subscribers" refid="provisioned-data">
> </region>
>
> <region name="Sessions" refid="provisioned-data">
> </region>
>
> <region name="Subscribers_meta" refid="provisioned-data">
> <region-attributes>
> <partition-attributes colocated-with="Subscribers" />
> </region-attributes>
> </region>
>
> <region name="Sessions_meta" refid="provisioned-data">
> <region-attributes>
> <partition-attributes colocated-with="Sessions" />
> </region-attributes>
> </region>
> </cache>
>
> -------------- client-cache.xml --------------
>
> <?xml version="1.0" encoding="UTF-8"?>
> <client-cache xmlns="http://geode.apache.org/schema/cache"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xsi:schemaLocation="http://geode.apache.org/schema/cache
> http://geode.apache.org/schema/cache/cache-1.0.xsd"
> version="1.0"
> copy-on-read="true" >
> <!-- ======= [ Deployment specific fragment ] ======== -->
> <pool name="provision-server-pool" subscription-enabled="true" >
> <locator host="dms-locator"
> port="10334" />
> </pool>
>
> <!-- ======= [ PDM specific fragment ] ========== -->
> <region name="Subscribers">
> <region-attributes refid="PROXY"
> pool-name="provision-server-pool" />
> </region>
> <region name="Sessions">
> <region-attributes refid="PROXY"
> pool-name="provision-server-pool" />
> </region>
> <region name="Subscribers_meta">
> <region-attributes refid="PROXY"
> pool-name="provision-server-pool"/>
> </region>
> <region name="Sessions_meta">
> <region-attributes refid="PROXY"
> pool-name="provision-server-pool"/>
> </region>
>
> </client-cache>
>
>
>
> On Tue, Sep 25, 2018 at 3:39 PM Jacob Barrett <jb...@pivotal.io> wrote:
>
>> Can you provide details on your server configuration, region
>> configuration, and client configuration?
>>
>> -Jake
>>
>>
>> On Sep 24, 2018, at 11:01 PM, Anibal Caceres Hernando <
>> anibal.caceres@gmail.com> wrote:
>>
>> 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 <ag...@pivotal.io>
>> 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 <
>>> anibal.caceres@gmail.com> 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.
>>>>
>>>
>
Re: Doubts about dealing with transactions isolation from
geode-native
Posted by Real Wes <Th...@outlook.com>.
And Subscribers_meta has the exact same key as Subscribers and Sessions_meta has the exact same key as Sessions?
Wes
On Sep 25, 2018, at 5:50 PM, Anibal Caceres Hernando <an...@gmail.com>> wrote:
Hi Jake,
Following are server-cache.xml, and client-cache.xml, please, let me know if you need more info. You'll see partitioned regions, but we have observed the issue also with replicated ones.
Kind regards,
Aníbal.
-------------- server-cache.xml --------------
<?xml version="1.0" encoding="UTF-8"?>
<cache xmlns="http://geode.apache.org/schema/cache"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://geode.apache.org/schema/cache http://geode.apache.org/schema/cache/cache-1.0.xsd"
version="1.0"
copy-on-read="true">
<!-- Topology information fragment -->
<region-attributes id="provisioned-data"
refid="PARTITION" />
<!-- Physical data model fragment -->
<region name="Subscribers" refid="provisioned-data">
</region>
<region name="Sessions" refid="provisioned-data">
</region>
<region name="Subscribers_meta" refid="provisioned-data">
<region-attributes>
<partition-attributes colocated-with="Subscribers" />
</region-attributes>
</region>
<region name="Sessions_meta" refid="provisioned-data">
<region-attributes>
<partition-attributes colocated-with="Sessions" />
</region-attributes>
</region>
</cache>
-------------- client-cache.xml --------------
<?xml version="1.0" encoding="UTF-8"?>
<client-cache xmlns="http://geode.apache.org/schema/cache"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://geode.apache.org/schema/cache http://geode.apache.org/schema/cache/cache-1.0.xsd"
version="1.0"
copy-on-read="true" >
<!-- ======= [ Deployment specific fragment ] ======== -->
<pool name="provision-server-pool" subscription-enabled="true" >
<locator host="dms-locator"
port="10334" />
</pool>
<!-- ======= [ PDM specific fragment ] ========== -->
<region name="Subscribers">
<region-attributes refid="PROXY"
pool-name="provision-server-pool" />
</region>
<region name="Sessions">
<region-attributes refid="PROXY"
pool-name="provision-server-pool" />
</region>
<region name="Subscribers_meta">
<region-attributes refid="PROXY"
pool-name="provision-server-pool"/>
</region>
<region name="Sessions_meta">
<region-attributes refid="PROXY"
pool-name="provision-server-pool"/>
</region>
</client-cache>
On Tue, Sep 25, 2018 at 3:39 PM Jacob Barrett <jb...@pivotal.io>> wrote:
Can you provide details on your server configuration, region configuration, and client configuration?
-Jake
On Sep 24, 2018, at 11:01 PM, Anibal Caceres Hernando <an...@gmail.com>> wrote:
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 <ag...@pivotal.io>> 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 <an...@gmail.com>> 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.
Re: Doubts about dealing with transactions isolation from geode-native
Posted by Anibal Caceres Hernando <an...@gmail.com>.
Hi Jake,
Following are server-cache.xml, and client-cache.xml, please, let me know
if you need more info. You'll see partitioned regions, but we have observed
the issue also with replicated ones.
Kind regards,
Aníbal.
-------------- server-cache.xml --------------
<?xml version="1.0" encoding="UTF-8"?>
<cache xmlns="http://geode.apache.org/schema/cache"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://geode.apache.org/schema/cache
http://geode.apache.org/schema/cache/cache-1.0.xsd"
version="1.0"
copy-on-read="true">
<!-- Topology information fragment -->
<region-attributes id="provisioned-data"
refid="PARTITION" />
<!-- Physical data model fragment -->
<region name="Subscribers" refid="provisioned-data">
</region>
<region name="Sessions" refid="provisioned-data">
</region>
<region name="Subscribers_meta" refid="provisioned-data">
<region-attributes>
<partition-attributes colocated-with="Subscribers" />
</region-attributes>
</region>
<region name="Sessions_meta" refid="provisioned-data">
<region-attributes>
<partition-attributes colocated-with="Sessions" />
</region-attributes>
</region>
</cache>
-------------- client-cache.xml --------------
<?xml version="1.0" encoding="UTF-8"?>
<client-cache xmlns="http://geode.apache.org/schema/cache"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://geode.apache.org/schema/cache
http://geode.apache.org/schema/cache/cache-1.0.xsd"
version="1.0"
copy-on-read="true" >
<!-- ======= [ Deployment specific fragment ] ======== -->
<pool name="provision-server-pool" subscription-enabled="true" >
<locator host="dms-locator"
port="10334" />
</pool>
<!-- ======= [ PDM specific fragment ] ========== -->
<region name="Subscribers">
<region-attributes refid="PROXY"
pool-name="provision-server-pool" />
</region>
<region name="Sessions">
<region-attributes refid="PROXY"
pool-name="provision-server-pool" />
</region>
<region name="Subscribers_meta">
<region-attributes refid="PROXY"
pool-name="provision-server-pool"/>
</region>
<region name="Sessions_meta">
<region-attributes refid="PROXY"
pool-name="provision-server-pool"/>
</region>
</client-cache>
On Tue, Sep 25, 2018 at 3:39 PM Jacob Barrett <jb...@pivotal.io> wrote:
> Can you provide details on your server configuration, region
> configuration, and client configuration?
>
> -Jake
>
>
> On Sep 24, 2018, at 11:01 PM, Anibal Caceres Hernando <
> anibal.caceres@gmail.com> wrote:
>
> 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 <ag...@pivotal.io>
> 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 <
>> anibal.caceres@gmail.com> 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.
>>>
>>
Re: Doubts about dealing with transactions isolation from geode-native
Posted by Jacob Barrett <jb...@pivotal.io>.
Can you provide details on your server configuration, region configuration, and client configuration?
-Jake
> On Sep 24, 2018, at 11:01 PM, Anibal Caceres Hernando <an...@gmail.com> wrote:
>
> 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 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 <ag...@pivotal.io> 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 <an...@gmail.com> 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.
Re: Doubts about dealing with transactions isolation from geode-native
Posted by Anibal Caceres Hernando <an...@gmail.com>.
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 <ag...@pivotal.io>
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 <
> anibal.caceres@gmail.com> 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.
>>
>
Re: Doubts about dealing with transactions isolation from geode-native
Posted by Anilkumar Gingade <ag...@pivotal.io>.
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 <
anibal.caceres@gmail.com> 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.
>