Back to bug 1024373
| Who | When | What | Removed | Added |
|---|---|---|---|---|
| Martin Gencur | 2013-10-29 14:31:24 UTC | Target Release | --- | 6.2.0 |
| Blocks | 1017190 | |||
| Martin Gencur | 2013-10-29 15:15:07 UTC | CC | mhusnain | |
| Red Hat Bugzilla | 2013-11-03 23:56:46 UTC | Doc Type | Bug Fix | Known Issue |
| Doc Type | Known Issue | Bug Fix | ||
| Radim Vansa | 2013-11-04 10:14:09 UTC | CC | rvansa | |
| Radim Vansa | 2013-11-04 10:14:49 UTC | Component | unspecified | Infinispan |
| Martin Gencur | 2013-11-05 11:29:35 UTC | CC | gsheldon | |
| Doc Text | Cause: Consequence: Workaround: Result: | |||
| Doc Type | Bug Fix | Known Issue | ||
| Doc Text | Cause: Consequence: Workaround: Result: | Cause: Transactional caches are configured with optimistic locking by default. Concurrent replace() calls might return true under contention and transactions might commit even if they're not supposed to. Consequence: Two concurrent commands, replace(key, A, B), replace(key, A, C) may both overwrite the entry. The command which is finalized later wins, overwriting an unexpected value with new value. Workaround: Enable REPEATABLE_READ isolation level and write skew check. Result: Concurrent replace operations work as expected. |
||
| Tristan Tarrant | 2013-11-19 13:43:20 UTC | Doc Text | Cause: Transactional caches are configured with optimistic locking by default. Concurrent replace() calls might return true under contention and transactions might commit even if they're not supposed to. Consequence: Two concurrent commands | Transactional caches are configured with optimistic locking by default. Concurrent replace() calls might return true under contention and transactions might commit even if they are not supposed to. Two concurrent commands, replace(key, A, B) |
| Doc Text | , replace(key, A, B), replace(key, A, C) may both overwrite the entry. The command which is finalized later wins | , replace(key, A, C) may both overwrite the entry. The command which is finalized later wins, overwriting an unexpected value with new value. As a workaround | ||
| Doc Text | , overwriting an unexpected value with new value. Workaround: Enable REPEATABLE_READ isolation level and write skew check. Result: Concurrent replace operations work as expected. | , enable REPEATABLE_READ isolation level and write skew check. This will result in concurrent replace operations working as expected. | ||
| Doc Text | Transactional caches are configured with optimistic locking by default. Concurrent replace() calls might return true under contention and transactions might commit even if they are not supposed to. Two concurrent commands, replace(key, A, B) | Transactional caches are configured with optimistic locking by default. Concurrent replace() calls might return true under contention and transactions might commit even if they are not supposed to. <para> </para> Two concurrent commands, replace(key | ||
| Doc Text | , replace(key, A, C) may both overwrite the entry. The command which is finalized later wins, overwriting an unexpected value with new value. As a workaround | , A, B), replace(key, A, C) may both overwrite the entry. The command which is finalized later wins, overwriting an unexpected value with new value. <para> </para> As a workaround | ||
| Doc Text | , enable REPEATABLE_READ isolation level and write skew check. This will result in concurrent replace operations working as expected. | , enable REPEATABLE_READ isolation level and write skew check. <para> </para> This will result in concurrent replace operations working as expected. | ||
| Doc Text | Transactional caches are configured with optimistic locking by default. Concurrent replace() calls might return true under contention and transactions might commit even if they are not supposed to. <para> </para> Two concurrent commands, replace(key | Transactional caches are configured with optimistic locking by default. Concurrent replace() calls might return true under contention and transactions might commit even if they are not supposed to. </para> <para> Two concurrent commands, replace(key | ||
| Doc Text | , A, B), replace(key, A, C) may both overwrite the entry. The command which is finalized later wins, overwriting an unexpected value with new value. <para> </para> As a workaround | , A, B), replace(key, A, C) may both overwrite the entry. The command which is finalized later wins, overwriting an unexpected value with new value. </para> <para> As a workaround | ||
| Doc Text | , enable REPEATABLE_READ isolation level and write skew check. <para> </para> This will result in concurrent replace operations working as expected. | , enable REPEATABLE_READ isolation level and write skew check. This will result in concurrent replace operations working as expected. | ||
| Target Release | 6.2.0 | 7.0.0 | ||
| Martin Gencur | 2013-12-10 11:35:52 UTC | Blocks | 1017190 | |
| Misha H. Ali | 2014-09-15 04:58:46 UTC | Doc Text | Transactional caches are configured with optimistic locking by default. Concurrent replace() calls might return true under contention and transactions might commit even if they are not supposed to. </para> <para> Two concurrent commands, replace(key, A, B), replace(key, A, C) may both overwrite the entry. The command which is finalized later wins, overwriting an unexpected value with new value. </para> <para> As a workaround, enable REPEATABLE_READ isolation level and write skew check. This will result in concurrent replace operations working as expected. | In Red Hat JBoss Data Grid, transactional caches are configured with optimistic locking by default. Concurrent <methodname>replace()</methodname> calls can return true under contention and transactions might unexpectedly commit. </para> <para> Two concurrent commands, replace(key, A, B), replace(key, A, C) may both overwrite the entry. The command which is finalized later wins, overwriting an unexpected value with new value. </para> <para> This is a known issue in JBoss Data Grid 6.3.1. As a workaround, enable write skew check and the <parameter>REPEATABLE_READ</parameter> isolation level. This results in concurrent replace operations working as expected. |
| Misha H. Ali | 2014-09-16 03:43:43 UTC | Doc Text | In Red Hat JBoss Data Grid, transactional caches are configured with optimistic locking by default. Concurrent <methodname>replace()</methodname> calls can return true under contention and transactions might unexpectedly commit. </para> <para> Two concurrent commands, replace(key, A, B), replace(key, A, C) may both overwrite the entry. The command which is finalized later wins, overwriting an unexpected value with new value. </para> <para> This is a known issue in JBoss Data Grid 6.3.1. As a workaround, enable write skew check and the <parameter>REPEATABLE_READ</parameter> isolation level. This results in concurrent replace operations working as expected. | In Red Hat JBoss Data Grid, transactional caches are configured with optimistic locking by default. Concurrent <methodname>replace()</methodname> calls can return true under contention and transactions might unexpectedly commit. Two concurrent commands, replace(key, A, B), replace(key, A, C) may both overwrite the entry. The command which is finalized later wins, overwriting an unexpected value with new value. This is a known issue in JBoss Data Grid 6.3.1. As a workaround, enable write skew check and the <parameter>REPEATABLE_READ</parameter> isolation level. This results in concurrent replace operations working as expected. |
| Misha H. Ali | 2014-11-10 04:57:17 UTC | Doc Text | In Red Hat JBoss Data Grid, transactional caches are configured with optimistic locking by default. Concurrent <methodname>replace()</methodname> calls can return true under contention and transactions might unexpectedly commit. Two concurrent commands, replace(key, A, B), replace(key, A, C) may both overwrite the entry. The command which is finalized later wins, overwriting an unexpected value with new value. This is a known issue in JBoss Data Grid 6.3.1. As a workaround, enable write skew check and the <parameter>REPEATABLE_READ</parameter> isolation level. This results in concurrent replace operations working as expected. | In Red Hat JBoss Data Grid, transactional caches are configured with optimistic locking by default. Concurrent <methodname>replace()</methodname> calls can return true under contention and transactions might unexpectedly commit. Two concurrent commands, <command>replace(key, A, B)</command> and <command>replace(key, A, C)</command> may both overwrite the entry. The command which is finalized later wins, overwriting an unexpected value with new value. This is a known issue in JBoss Data Grid 6.4 Beta. As a workaround, enable write skew check and the <parameter>REPEATABLE_READ</parameter> isolation level. This results in concurrent replace operations working as expected. |
| Misha H. Ali | 2015-01-18 23:49:05 UTC | Doc Text | In Red Hat JBoss Data Grid, transactional caches are configured with optimistic locking by default. Concurrent <methodname>replace()</methodname> calls can return true under contention and transactions might unexpectedly commit. Two concurrent commands, <command>replace(key, A, B)</command> and <command>replace(key, A, C)</command> may both overwrite the entry. The command which is finalized later wins, overwriting an unexpected value with new value. This is a known issue in JBoss Data Grid 6.4 Beta. As a workaround, enable write skew check and the <parameter>REPEATABLE_READ</parameter> isolation level. This results in concurrent replace operations working as expected. | In Red Hat JBoss Data Grid, transactional caches are configured with optimistic locking by default. Concurrent <methodname>replace()</methodname> calls can return true under contention and transactions might unexpectedly commit. Two concurrent commands, <command>replace(key, A, B)</command> and <command>replace(key, A, C)</command> may both overwrite the entry. The command which is finalized later wins, overwriting an unexpected value with new value. This is a known issue in JBoss Data Grid 6.4. As a workaround, enable write skew check and the <parameter>REPEATABLE_READ</parameter> isolation level. This results in concurrent replace operations working as expected. |
| Christian Huffman | 2015-04-02 12:45:08 UTC | CC | chuffman | |
| PnT Account Manager | 2018-09-12 22:21:32 UTC | CC | gsheldon | |
| PnT Account Manager | 2018-09-12 22:31:36 UTC | CC | mhusnain | |
| Red Hat Bugzilla | 2022-12-31 23:44:52 UTC | CC | rvansa |
Back to bug 1024373