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