You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@geode.apache.org by Alberto Gomez <al...@est.tech> on 2021/02/09 15:28:11 UTC
Question about Geode transactions
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
Re: Question about Geode transactions
Posted by Dave Barnes <db...@apache.org>.
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 <al...@est.tech>
wrote:
> Eric, thanks a lot for your answer.
>
> Best regards,
>
> Alberto
> ------------------------------
> *From:* Eric Shu <es...@vmware.com>
> *Sent:* Thursday, February 18, 2021 6:27 PM
> *To:* user@geode.apache.org <us...@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 <al...@est.tech>
> *Sent:* Tuesday, February 16, 2021 3:28 AM
> *To:* user@geode.apache.org <us...@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 <db...@apache.org>
> *Sent:* Tuesday, February 9, 2021 9:39 PM
> *To:* user@geode.apache.org <us...@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 <al...@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>
> >
>
Re: Question about Geode transactions
Posted by Alberto Gomez <al...@est.tech>.
Eric, thanks a lot for your answer.
Best regards,
Alberto
________________________________
From: Eric Shu <es...@vmware.com>
Sent: Thursday, February 18, 2021 6:27 PM
To: user@geode.apache.org <us...@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 <al...@est.tech>
Sent: Tuesday, February 16, 2021 3:28 AM
To: user@geode.apache.org <us...@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 <db...@apache.org>
Sent: Tuesday, February 9, 2021 9:39 PM
To: user@geode.apache.org <us...@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 <al...@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>
>
Re: Question about Geode transactions
Posted by Eric Shu <es...@vmware.com>.
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 <al...@est.tech>
Sent: Tuesday, February 16, 2021 3:28 AM
To: user@geode.apache.org <us...@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 <db...@apache.org>
Sent: Tuesday, February 9, 2021 9:39 PM
To: user@geode.apache.org <us...@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 <al...@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>
>
Re: Question about Geode transactions
Posted by Alberto Gomez <al...@est.tech>.
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 <db...@apache.org>
Sent: Tuesday, February 9, 2021 9:39 PM
To: user@geode.apache.org <us...@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 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 <al...@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
>
Re: Question about Geode transactions
Posted by Dave Barnes <db...@apache.org>.
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 <al...@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
>