[infinispan-dev] rethinking ISPN transactions

Mircea Markus mmarkus at redhat.com
Tue Nov 12 09:33:30 EST 2013


Hi Scott,


On Nov 12, 2013, at 3:29 PM, Scott Marlow <smarlow at redhat.com> wrote:

> Would these changes impact the WildFly transaction mode [5]?  Is the 
> WildFly "NON_XA" transaction mode mapping to the 1PC option?

no, that only has to do with the way transactions are enlisted with the transaction manager: as XAResources (XA) or as synchronizations (NON_XA)

>  Or Does 
> WildFly NON_XA map to something else in Infinispan?

yes, to javax.transaction.Synchronization (vs. javax.transaction.XAResource) based enlistment.

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

it should still work (but it needs to be tested). 
Thanks for the input!

> 
> [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,
>> 
> 
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

Cheers,
-- 
Mircea Markus
Infinispan lead (www.infinispan.org)







More information about the infinispan-dev mailing list