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