[infinispan-dev] rethinking ISPN transactions

[Scott Marlow]

Would these changes impact the WildFly transaction mode [5]?  Is the 
WildFly "NON_XA" transaction mode mapping to the 1PC option?  Or Does 
WildFly NON_XA map to something else in Infinispan?

I'm not sure how this would impact WFLY-2267 [6], which is about 
attempting to register a synchronization too late.

[5] 
https://github.com/wildfly/wildfly/blob/master/build/src/main/resources/docs/schema/jboss-as-infinispan_2_0.xsd#L885

[6] https://issues.jboss.org/browse/WFLY-2267

On 11/08/2013 10:28 AM, Mircea Markus wrote:
> Hey guys,
>
> Several things were discussed lately([1],[2],[3],[4]) around our transaction support. Here's some some thoughts I have around re-modeling transactions for 7.0:
>
> 1. Async options for commit/rollback
> - 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
>
>
> [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
>
>
> Cheers,
>