Alberto, I've created a JIRA ticket to track this fix and assigned it to myself: https://issues.apache.org/jira/browse/GEODE-8953. Thanks for catching this problem and following it up.
On Thu, Feb 18, 2021 at 9:55 AM Alberto Gomez <alberto.go...@est.tech> wrote: > Eric, thanks a lot for your answer. > > Best regards, > > Alberto > ------------------------------ > *From:* Eric Shu <e...@vmware.com> > *Sent:* Thursday, February 18, 2021 6:27 PM > *To:* user@geode.apache.org <user@geode.apache.org> > *Subject:* Re: Question about Geode transactions > > The following statement still applies when transactional operations > combined with non-transactional operations. > "If other, non-transactional sources update the keys the transaction is > modifying, the changes may intermingle with this transaction’s changes. The > other sources can include distributions from remote members, loading > activities, and other direct cache modification calls from the same member. > When this happens, after your commit finishes, the cache state may not be > what you expected." > > To achieve best performance, non-transactional operations do not acquire > DLock used to check conflicts in a transaction. So transaction will not be > able to detect the conflict caused by a non transactional operation. It is > expected that user application always uses transaction or no transaction at > all, unless user knows that certain regions or set of entries will not be > modified by operations outside of a transaction. > > Regards, > Eric > ------------------------------ > *From:* Alberto Gomez <alberto.go...@est.tech> > *Sent:* Tuesday, February 16, 2021 3:28 AM > *To:* user@geode.apache.org <user@geode.apache.org> > *Subject:* Re: Question about Geode transactions > > Thanks for your answer, Dave. > > I would appreciate then, if some transaction expert could confirm or deny > that the removed paragraph still applies to Geode: > > "If other, non-transactional sources update the keys the transaction is > modifying, the changes may intermingle with this transaction’s changes. The > other sources can include distributions from remote members, loading > activities, and other direct cache modification calls from the same member. > When this happens, after your commit finishes, the cache state may not be > what you expected." > > Once that is clarified, I think it would be useful to have this > information explicit in the documentation. > > Thanks in advance, > > Alberto G. > ------------------------------ > *From:* Dave Barnes <dbar...@apache.org> > *Sent:* Tuesday, February 9, 2021 9:39 PM > *To:* user@geode.apache.org <user@geode.apache.org> > *Subject:* Re: Question about Geode transactions > > Alberto, > As you know, I'm a docs contributor, not a transaction expert, so I'll > leave to someone else to comment on the specific behaviors and precautions > you ask about. > > The doc change was prompted by the writers' ongoing efforts (throughout > the user guide) to focus on what Geode does and to reduce the amount of > case-by-case detail that can obscure the point. > The section "Adherence to ACID Promises" > https://geode.apache.org/docs/guide/113/developing/transactions/transactions_intro.html > <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgeode.apache.org%2Fdocs%2Fguide%2F113%2Fdeveloping%2Ftransactions%2Ftransactions_intro.html&data=04%7C01%7Ceshu%40vmware.com%7C034c8861f194405b877a08d8d26df801%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637490717053867402%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=hV84TJmwfOLtaTd4NzFNZAVIcTprYwNUZdkJsFkVdho%3D&reserved=0> > describes, in a more general way, what to expect when using Geode > transactions: > "Geode implements optimistic transactions, choosing the much higher > transaction performance they offer over the slow, locking methods of a > traditional relational database. > Optimistic transaction semantics are not identical to the > Atomicity-Consistency-Isolation-Durability (ACID) semantics of a > traditional relational database." > > We draw the 'cut line' of what to keep and what to discard in consultation > with implementors and users through the open-source mailing lists and pull > requests. > > The pull request for this change contains plenty of detail: > https://github.com/apache/geode/pull/2304 > <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Fpull%2F2304&data=04%7C01%7Ceshu%40vmware.com%7C034c8861f194405b877a08d8d26df801%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637490717053877394%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=gmd1RpcU%2BDJkRKR9UohxAXFFFCdMV1Io3spwkWjb%2Bjs%3D&reserved=0>. > You'll see that I was the one who proposed deleting much of the 'old' > material, including the section you quote. > > If you'd like to request that a section be reinstated, or that greater > detail is needed, please open a JIRA ticket to that effect. > > Best regards, > Dave Barnes > > On 2021/02/09 15:28:11, Alberto Gomez <alberto.go...@est.tech> wrote: > > Hi, > > > > Running some tests with transactions and non-transactional puts I have > ran into a situation that I did not expect. > > > > The observation was that a Geode transaction would not always detect > conflicting changes done by a simultaneous non-transactional put. According > to my tests, conflicting changes done by puts were detected most of the > times by the transaction, but some other times they were not, depending on > the moment at which the put occurred with respect to the transaction. > > > > The Geode documentation does not provide a lot of detail about how > transactions work although I found the following piece of information in > the Geode 1.6 documentation ([1]) that seemed to confirm what I experienced > in my tests: > > > > "If other, non-transactional sources update the keys the transaction is > modifying, the changes may intermingle with this transaction’s changes. The > other sources can include distributions from remote members, loading > activities, and other direct cache modification calls from the same member. > When this happens, after your commit finishes, the cache state may not be > what you expected." > > > > Could someone please confirm that what this information states is true > currently in Geode? > > > > If that is true, do you have any suggestion about how to avoid it (i.e. > if one client uses transactions, all clients should use transactions too so > that puts do not overwrite sometimes the writes of transactions)? > > > > Also, could someone please tell why this information about how > transactions work was removed from the Geode documentation? > > > > Thanks in advance, > > > > Alberto G. > > > > [1] > https://geode.apache.org/docs/guide/16/developing/transactions/how_cache_transactions_work.html#topic_fls_1j1_wk > <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgeode.apache.org%2Fdocs%2Fguide%2F16%2Fdeveloping%2Ftransactions%2Fhow_cache_transactions_work.html%23topic_fls_1j1_wk&data=04%7C01%7Ceshu%40vmware.com%7C034c8861f194405b877a08d8d26df801%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637490717053877394%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=7huVCst34XCyBucDE8u8ioxrN8ybggdQpA1AE8tnnPg%3D&reserved=0> > > >
