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(DONE)- 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(DONE)- 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 of 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
- incorporates
-
ISPN-7507 Deprecate asynchronous options for transactional cache
- Closed
-
ISPN-7632 Remove useEagerLocking configuration
- Closed
-
ISPN-3730 Revisit Infinsipan's transactions
- Closed
-
ISPN-5600 Optimize transactions on multiple caches
- Closed
- is related to
-
ISPN-3655 Default optimistic locking configuration leads to inconsistency
- Closed
-
ISPN-11272 RecoveryManagerImpl should use Caffeine map
- Closed