Hello Pieter, Your understanding seems correct, yes. Whenever a member fails to complete the transaction logic (which includes disk writes), it should be removed from the distributed system and, upon a successful restart, it should also rebuild its state from surviving members that successfully complete the updates. Meaning that the disk-store will eventually be consistent across the cluster. You might want to implement a TransactionWriter [1], anyway, and log all transactions so you can recover the data manually if every single member fails while a transaction is being committed. Best regards.
[1]: https://geode.apache.org/docs/guide/14/developing/events/list_of_event_handlers_and_events.html On Wed, Feb 7, 2018 at 10:15 AM, Pieter van Zyl <[email protected]> wrote: > Hi Juan > > Thanks for the quick response! > > I have taken a look at that link and will re-read it again during the day. > > Based on a quick look now is it correct to say that there well be > transactional consistency on the Regions in-memory? > It will succeed or fail on the Region in-memory. Even the persistent > region. BUT the rest, to write changes to a persistent region to disk, > cannot be transactionally guaranteed? > > Will there be eventual consistency to the disk as in other NoSQL databases > for example? > > Kindly > Pieter > > > > On Wed, Feb 7, 2018 at 11:11 AM, Juan José Ramos <[email protected]> > wrote: > >> Hello Pieter!!, >> >> By default, Geode does not allow transactions on persistent regions, this >> is why you're getting the exception in the first place. You can enable the >> use of transactions on persistent regions by setting the property >> *gemfire.ALLOW_PERSISTENT_TRANSACTIONS* to *true*, anyway. Keep in mind, >> however, that Geode does not provide atomic disk persistence guarantees, >> that's why the default behavior is to disallow disk-persistent regions from >> participating in transactions. >> For more details about this, please have a look at Transactions and >> Persistent Regions [1] within the user guide. >> Hope this helps, cheers. >> >> [1]: https://geode.apache.org/docs/guide/14/developing/trans >> actions/cache_transactions_by_region_type.html >> >> On Wed, Feb 7, 2018 at 6:54 AM, Pieter van Zyl <[email protected] >> > wrote: >> >>> Good day. >>> >>> We have added transactions using Geode and are now getting this >>> exception as soon as we try and lookup something from a region: >>> >>> rg.apache.geode.cache.client.ServerOperationException: remote server on >>> rfc(5196:loner):60112:c13ffd6e: While performing a remote get >>> >>> at org.apache.geode.cache.client.internal.AbstractOp.processObj >>> Response(AbstractOp.java:295) >>> at org.apache.geode.cache.client.internal.GetOp$GetOpImpl.proce >>> ssResponse(GetOp.java:143) >>> at org.apache.geode.cache.client.internal.AbstractOp.attemptRea >>> dResponse(AbstractOp.java:213) >>> at org.apache.geode.cache.client.internal.AbstractOp.attempt(Ab >>> stractOp.java:392) >>> at org.apache.geode.cache.client.internal.ConnectionImpl.execut >>> e(ConnectionImpl.java:280) >>> at org.apache.geode.cache.client.internal.pooling.PooledConnect >>> ion.execute(PooledConnection.java:332) >>> at org.apache.geode.cache.client.internal.OpExecutorImpl.execut >>> eWithPossibleReAuthentication(OpExecutorImpl >>> >>> *Caused by: java.lang.UnsupportedOperationException: Operations on >>> persist-backup regions are not allowed because this thread has an active >>> transaction* >>> at org.apache.geode.internal.cache.TXRegionState.<init>(TXRegio >>> nState.java:61) >>> >>> We get this error when trying to access the RootMapHolder region setup >>> below. >>> >>> We have a client connecting to a server. The relevant client config is >>> basically: >>> >>> <bean id="pdxSerializer" class="org.rdb.session.geode.R >>> DBGeodeSerializer"> >>> <constructor-arg value="org.rdb.*,net.lautus.*"/> >>> </bean> >>> >>> >>> <util:properties id="gemfire-props"> >>> <prop key="log-level">config</prop> >>> </util:properties> >>> >>> <gfe:client-cache properties-ref="gemfire-props" >>> pdx-serializer-ref="pdxSerializer"/> >>> <gfe:transaction-manager copy-on-read="true"/> >>> >>> >>> <gfe:pool> >>> <gfe:server host="localhost" port="40407"/> >>> </gfe:pool> >>> >>> >>> <gfe:client-region id="org.rdb.internal.session.rootmap.RootMapHolder" >>> shortcut="CACHING_PROXY_OVERFLOW" >>> ignore-if-exists="true"/> >>> >>> >>> >>> On the server we have this config part: >>> >>> util:properties id="gemfire-props"> >>> <prop key="log-level">info</prop> >>> <prop key="mcast-port">0</prop> >>> >>> >>> </util:properties> >>> >>> >>> <gfe:cache properties-ref="gemfire-props" pdx-serializer-ref="pdxSerializer" >>> pdx-persistent="true" >>> pdx-disk-store="pdx-disk-store" /> >>> >>> >>> <gfe:cache-server auto-startup="true" bind-address="localhost" >>> port="40407" host-name-for-clients="localhost" >>> max-connections="1"/> >>> >>> <bean id="pdxSerializer" class="org.rdb.session.geode.R >>> DBGeodeSerializer"> >>> <constructor-arg value="org.rdb.*,net.lautus.*"/> >>> </bean> >>> >>> <gfe:replicated-region id="org.rdb.internal.session.r >>> ootmap.RootMapHolder" >>> disk-store-ref="testDiskStore" >>> persistent="true"> >>> <!--<gfe:cache-listener ref="cacheListener"/>--> >>> <gfe:eviction type="HEAP_PERCENTAGE" action="OVERFLOW_TO_DISK"/> >>> </gfe:replicated-region> >>> >>> >>> <gfe:disk-store id="testDiskStore"> >>> <gfe:disk-dir location="geode-test/testDiskStore"/> >>> </gfe:disk-store> >>> >>> >>> <gfe:disk-store id="pdx-disk-store"> >>> <gfe:disk-dir location="geode-test/pdx"/> >>> </gfe:disk-store> >>> >>> >>> We are getting and starting transactions via: >>> >>> transactionManager = context.getBean("gemfireTransactionManager", >>> GemfireTransactionManager.class); >>> >>> cacheTransactionManager = transactionManager.getCache(). >>> getCacheTransactionManager(); >>> >>> cacheTransactionManager.begin(); >>> >>> By debugging I can see we start only one transaction. But as soon as we >>> access the first Region it throws this error. >>> >>> We are not using annotations and Spring repositories as we are trying to >>> add Geode to an existing project that has no Spring, Spring Data or JPA >>> support. >>> >>> Are we using transactions incorrectly? Or is this a Region setup issue? >>> >>> Any help would be appreciated. Can provide more detail if required. >>> >>> >>> Kindly >>> >>> Pieter >>> >> >> >> >> -- >> Juan José Ramos Cassella >> Senior Technical Support Engineer >> Email: [email protected] >> Office#: +353 21 4238611 <+353%2021%20423%208611> >> Mobile#: +353 87 2074066 <+353%2087%20207%204066> >> After Hours Contact#: +1 877 477 2269 <(877)%20477-2269> >> Office Hours: Mon - Thu 08:30 - 17:00 GMT. Fri 08:30 - 16:00 GMT >> How to upload artifacts: https://support.pivotal.io/hc/ >> en-us/articles/204369073 >> How to escalate a ticket: https://support.pivotal.io/hc/ >> en-us/articles/203809556 >> >> [image: support] <https://support.pivotal.io/> [image: twitter] >> <https://twitter.com/pivotal> [image: linkedin] >> <https://www.linkedin.com/company/3048967> [image: facebook] >> <https://www.facebook.com/pivotalsoftware> [image: google plus] >> <https://plus.google.com/+Pivotal> [image: youtube] >> <https://www.youtube.com/playlist?list=PLAdzTan_eSPScpj2J50ErtzR9ANSzv3kl> >> > > -- Juan José Ramos Cassella Senior Technical Support Engineer Email: [email protected] Office#: +353 21 4238611 Mobile#: +353 87 2074066 After Hours Contact#: +1 877 477 2269 Office Hours: Mon - Thu 08:30 - 17:00 GMT. Fri 08:30 - 16:00 GMT How to upload artifacts: https://support.pivotal.io/hc/en-us/articles/204369073 How to escalate a ticket: https://support.pivotal.io/hc/en-us/articles/203809556 [image: support] <https://support.pivotal.io/> [image: twitter] <https://twitter.com/pivotal> [image: linkedin] <https://www.linkedin.com/company/3048967> [image: facebook] <https://www.facebook.com/pivotalsoftware> [image: google plus] <https://plus.google.com/+Pivotal> [image: youtube] <https://www.youtube.com/playlist?list=PLAdzTan_eSPScpj2J50ErtzR9ANSzv3kl>
