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 <[email protected]> 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 <
> [email protected]> 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 <[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.
>>>
>>
