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