[ https://issues.jboss.org/browse/ISPN-3927?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-3927: ------------------------------ Description: Umbrella JIRA for several transaction related improvements: -1. Async options for commit/rollback- (DONE) - they don't really make sense as a user you don't get any guarantee on the status of the transaction - they complicate the code significantly - I think they should be removed 2. READ_COMMITTED - it has the same performance as REPEATABLE_READ, but offers less guarantees. - unlike REPEATABLE_READ, it also behaves inconsistently when the data is owned by transaction originator - I think it should be removed 3. Optimistic tx without Write Skew Check (WSC) - well, without WSC the transactions are not optimistic by definition - they are something else: an batch update of multiple key/values. If the batch is successful you know the update was atomic. If it failed you don't get any guarantee - suggestion: optimistic tx should *always* have WSC enabled (no option to configure it) - build our batching functionality on top of what currently is optimistic tx without WSC and document it as such 4. Remove 1PC option - I'm not totally sure about it, but does it really make sense to have 1PC as an option? they don't offer any consistency guarantees so async API + non tx do about the same thing 5. Configuration changes - remove (deprecate first) {{write-skew}} attribute. it will be enabled automatically when needed to keep the data consistent - remove {{eager-locking-single-node}}. deprecated since 5.1 - remove {{transaction-protocol}} and add {{TOTAL_ORDER}} to {{locking-mode}}. Since total order is an alternative, it makes more sense to be in the locking mode than in the separate attributed. - remove {{eager-locking}}. deprecated since 5.1 - move {{isolation-level}} to {{<transaction>}}. it only makes sense for transactional caches. - remove {{single-phase-auto-commit}} ?? it is 1PC for auto-commit transactions. does it make sense to have it? it doesn't provide any guarantees. 6. Internal changes - remove list {{WriteCommand}} and keep a map between {{key}} and {{new-value, new-metadata and version-read}}. A {{null}} value means a remove operation. 7. Create a single {{XaResource}}/{{Synchronization}} per cache-manager instead of per cache. 8. For implicit transaction and {{auto-commit=true}}, if the transaction fails to commit, it can be retried until succeed. This will make the conditional operation to return a valid return value. Possible problem with retry is when a partition happens and it may fail the transaction forever. - note: conditional operations that return {{true}} or {{false}} doesn't need to retry the transaction. They can return {{false}} when the transaction fails. [1] http://markmail.org/thread/a7fjko4dyejxqgdy [2] https://github.com/infinispan/infinispan/pull/2177 [3] http://infinispan.markmail.org/thread/nl2bs7rjvayjcybv [4] http://infinispan.markmail.org/thread/vbg6g4otu7djazbc was: Umbrella JIRA for several transaction related improvements: -1. Async options for commit/rollback- (DONE) - they don't really make sense as a user you don't get any guarantee on the status of the transaction - they complicate the code significantly - I think they should be removed 2. READ_COMMITTED - it has the same performance as REPEATABLE_READ, but offers less guarantees. - unlike REPEATABLE_READ, it also behaves inconsistently when the data is owned by transaction originator - I think it should be removed 3. Optimistic tx without Write Skew Check (WSC) - well, without WSC the transactions are not optimistic by definition - they are something else: an batch update of multiple key/values. If the batch is successful you know the update was atomic. If it failed you don't get any guarantee - suggestion: optimistic tx should *always* have WSC enabled (no option to configure it) - build our batching functionality on top of what currently is optimistic tx without WSC and document it as such 4. Remove 1PC option - I'm not totally sure about it, but does it really make sense to have 1PC as an option? they don't offer any consistency guarantees so async API + non tx do about the same thing 5. Configuration changes - remove (deprecate first) {{write-skew}} attribute. it will be enabled automatically when needed to keep the data consistent - remove {{eager-locking-single-node}}. deprecated since 5.1 - remove {{transaction-protocol}} and add {{TOTAL_ORDER}} to {{locking-mode}}. Since total order is an alternative, it makes more sense to be in the locking mode than in the separate attributed. - remove {{eager-locking}}. deprecated since 5.1 - move {{isolation-level}} to {{<transaction>}}. it only makes sense for transactional caches. - remove {{single-phase-auto-commit}} ?? it is 1PC for auto-commit transactions. does it make sense to have it? it doesn't provide any guarantees. 6. Internal changes - remove list {{WriteCommand}} and keep a map between {{key}} and {{new-value, new-metadata and version-read}}. A {{null}} value means a remove operation. 7. Create a single {{XaResource}}/{{Synchronization}} per cache-manager instead of per cache. 8. For implicit transaction and {{auto-commit=true}}, if the transaction fails to commit, it can be retried until succeed. This will make the conditional operation to return a valid return value. Possible problem with retry is when a partition happens and it may fail the transaction forever. [1] http://markmail.org/thread/a7fjko4dyejxqgdy [2] https://github.com/infinispan/infinispan/pull/2177 [3] http://infinispan.markmail.org/thread/nl2bs7rjvayjcybv [4] http://infinispan.markmail.org/thread/vbg6g4otu7djazbc -- This message was sent by Atlassian JIRA (v7.2.3#72005)