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. >>>> >>> >
