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,

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, -- Mircea Markus Infinispan lead (www.infinispan.org) _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

On Nov 8, 2013, at 4:28 PM, Mircea Markus <mmarkus(a)redhat.com&gt; 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 So, they're always sync, right? > 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 +1. So, if you remove RC, and we only have RR, you can get rid of the isolation level configuration property altogether? We don't implement SERIALIZABLE, nor READ_UNCOMMITTED. > 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) +1 FYI, this means that the default OL behaivour changes. To be more precise, here's [1] a Gist with the difference in expectations for default configuration. [1] https://gist.github.com/galderz/9ba22e47116906a750d7 > - 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 > > [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, > -- > Mircea Markus > Infinispan lead (www.infinispan.org) > > > > > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Galder Zamarreño galder(a)redhat.com twitter.com/galderz Project Lead, Escalante http://escalante.io Engineer, Infinispan http://infinispan.org _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

Yet one more request: clear behaviour should be specified there as well - there was some discussion about txs and clear few months ago (I think fired by Sanne), but I have a feeling that it just got burried in the mailing list without any concrete result.

Radim On 11/12/2013 01:26 PM, Radim Vansa wrote: > Mircea, besides mentioning of removed stuff, would it be possible to > compile some list of supported transactional modes and *expected > behaviour*? (using short code snippets: in one mode this will fail, in > other one succeed) Ideally, total order could be included there as well. > > This list should provide the rationale for each mode. Maybe I could then > provide some numbers for each mode to let user see whether the lower > guarantees are worth the performance impact. > > Also, I'd like to see there presented the problem with transactional > reads - to let users know that if you write two values inside the > transaction and commit it, in another transaction you may read one of > the entries as appeared before the commit and another as appeared after. > I know that this can be evaded by force locking, and I understand why > this happens but when user reads /transactions/, he sees /ACID > properties/. And this (default) unexpected behaviour kind of breaks > isolation - user needs to be aware of that (and I haven't seen this > written down anywhere in the docs). > > Radim > > On 11/12/2013 12:56 PM, Galder Zamarreño wrote: >> On Nov 8, 2013, at 4:28 PM, Mircea Markus <mmarkus(a)redhat.com&gt; 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 >> So, they're always sync, right? >> >>> 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 >> +1. So, if you remove RC, and we only have RR, you can get rid of the isolation level configuration property altogether? We don't implement SERIALIZABLE, nor READ_UNCOMMITTED. >> >>> 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) >> +1 >> >> FYI, this means that the default OL behaivour changes. To be more precise, here's [1] a Gist with the difference in expectations for default configuration. >> >> [1] https://gist.github.com/galderz/9ba22e47116906a750d7 >> >>> - 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 >> >>> [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, >>> -- >>> Mircea Markus >>> Infinispan lead (www.infinispan.org) >>> >>> >>> >>> >>> >>> _______________________________________________ >>> infinispan-dev mailing list >>> infinispan-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >> -- >> Galder Zamarreño >> galder(a)redhat.com >> twitter.com/galderz >> >> Project Lead, Escalante >> http://escalante.io >> >> Engineer, Infinispan >> http://infinispan.org >> >> >> _______________________________________________ >> infinispan-dev mailing list >> infinispan-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/infinispan-dev > -- Radim Vansa <rvansa(a)redhat.com&gt; JBoss DataGrid QA _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

On Nov 12, 2013, at 1:26 PM, Radim Vansa <rvansa(a)redhat.com&gt; wrote: > Mircea, besides mentioning of removed stuff, would it be possible to > compile some list of supported transactional modes and *expected > behaviour*? (using short code snippets: in one mode this will fail, in > other one succeed) Ideally, total order could be included there as well. +1. sounds like a good idea to me. > This list should provide the rationale for each mode. The rationale between using optimistic vs pessimistic transaction is not going to be obvious from the code snippets, but requires text explanations[1]. I get your point though.

[1] http://blog.infinispan.org/2011/10/transaction-remake-in-infinispan-51.html > Maybe I could then > provide some numbers for each mode to let user see whether the lower > guarantees are worth the performance impact. > > Also, I'd like to see there presented the problem with transactional > reads - to let users know that if you write two values inside the > transaction and commit it, in another transaction you may read one of > the entries as appeared before the commit and another as appeared after. > I know that this can be evaded by force locking, and I understand why > this happens but when user reads /transactions/, he sees /ACID > properties/. And this (default) unexpected behaviour kind of breaks > isolation - user needs to be aware of that (and I haven't seen this > written down anywhere in the docs). Good point, again more related to documentation. Cheers,

Mircea, besides mentioning of removed stuff, would it be possible to compile some list of supported transactional modes and *expected behaviour*? (using short code snippets: in one mode this will fail, in other one succeed) Ideally, total order could be included there as well.

This list should provide the rationale for each mode. Maybe I could then provide some numbers for each mode to let user see whether the lower guarantees are worth the performance impact. Also, I'd like to see there presented the problem with transactional reads - to let users know that if you write two values inside the transaction and commit it, in another transaction you may read one of the entries as appeared before the commit and another as appeared after. I know that this can be evaded by force locking, and I understand why this happens but when user reads /transactions/, he sees /ACID properties/. And this (default) unexpected behaviour kind of breaks isolation - user needs to be aware of that (and I haven't seen this written down anywhere in the docs). Radim On 11/12/2013 12:56 PM, Galder Zamarreño wrote: > On Nov 8, 2013, at 4:28 PM, Mircea Markus <mmarkus(a)redhat.com&gt; 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 > So, they're always sync, right? > >> 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 > +1. So, if you remove RC, and we only have RR, you can get rid of the isolation level configuration property altogether? We don't implement SERIALIZABLE, nor READ_UNCOMMITTED. > >> 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) > +1 > > FYI, this means that the default OL behaivour changes. To be more precise, here's [1] a Gist with the difference in expectations for default configuration. > > [1] https://gist.github.com/galderz/9ba22e47116906a750d7 > >> - 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 > >> >> [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, >> -- >> Mircea Markus >> Infinispan lead (www.infinispan.org) >> >> >> >> >> >> _______________________________________________ >> infinispan-dev mailing list >> infinispan-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/infinispan-dev > > -- > Galder Zamarreño > galder(a)redhat.com > twitter.com/galderz > > Project Lead, Escalante > http://escalante.io > > Engineer, Infinispan > http://infinispan.org > > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev

On 11/12/2013 11:56 AM, Galder Zamarreño wrote: > > On Nov 8, 2013, at 4:28 PM, Mircea Markus <mmarkus(a)redhat.com&gt; 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 > > So, they're always sync, right? > >> 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 > > +1. So, if you remove RC, and we only have RR, you can get rid of the isolation level configuration property altogether? We don't implement SERIALIZABLE, nor READ_UNCOMMITTED. actually, I have plans to introduce UPDATE-SERIALIZABLE consistency :)

On Nov 12, 2013, at 3:12 PM, Pedro Ruivo <pedro(a)infinispan.org&gt; wrote: > On 11/12/2013 11:56 AM, Galder Zamarreño wrote: >> >> On Nov 8, 2013, at 4:28 PM, Mircea Markus <mmarkus(a)redhat.com&gt; 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 >> >> So, they're always sync, right? >> >>> 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 >> >> +1. So, if you remove RC, and we only have RR, you can get rid of the isolation level configuration property altogether? We don't implement SERIALIZABLE, nor READ_UNCOMMITTED. > > actually, I have plans to introduce UPDATE-SERIALIZABLE consistency :) I never get my head around this: what's the difference between UPDATE-SERIALIZABLE and one-copy serializable? :-)

Cheers,

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/d... [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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

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 OK, but can you elaborate on the last bullet? So, the batching API will no longer contain transactional guarantees?

On 11/19/2013 03:06 AM, Mircea Markus wrote: > On Nov 12, 2013, at 2:51 PM, Paul Ferraro <paul.ferraro(a)redhat.com&gt; wrote: > >> 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 >> OK, but can you elaborate on the last bullet? >> So, the batching API will no longer contain transactional guarantees? > The batching API ATM only guarantees that if the commit(end of batch) succeeds everything is applied. If the commit doesn't succeed you get inconsistencies/no guarantees. That's pretty much the kind of guarantees I'd like the new batching to offer. Are you sure that if commit doesn't fail, the batch is applied? Does batching use synchronisation or XA resource enlistment (or, are both options possible? In TransactionFactory I see that batching results in *_NOXA enum)? Because if it is synchronization and CommitCommand fails due to replication timeout, heuristic rollback is applied but the application does not receive any kind of exception.

Pardon me if I am mixing things, I am not well educated in all the JTA stuff but recently I got pretty surprised that with default settings my transaction was rolled back but the app code did not get any failure.

Radim -- Radim Vansa <rvansa(a)redhat.com&gt; JBoss DataGrid QA _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

-> this is quite a subtle aspect of JTA transactions (is Synchronisation.afterCompletion failures are not propagated to the user) - you have a very good point here, thanks! This right here has burned me very badly. I think this really needs to be called out, especially if we're using this mode rather than full-blown XA. Erik _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

Maybe synchronization support is another thing that we should scrap in 7.0, then?

BTW, I've also seen the transaction timeout that Radim mentioned, but only recently. I wonder if we could do anything to increase it for the stress tests.

Is there any reason to use synchronization other than "it's faster"?

IMO, the reasoning for removing synchronizations is the same as item 1 in your proposal, "Async options for commit/rollback". On Tue, Nov 19, 2013 at 6:35 PM, Mircea Markus <mmarkus(a)redhat.com&gt; wrote: On Nov 19, 2013, at 4:01 PM, Dan Berindei <dan.berindei(a)gmail.com&gt; wrote: > Maybe synchronization support is another thing that we should scrap in 7.0, then? I'd still allow them (sync enlistment is there for a resaon), but have XA+recovery enabled by default and the batching commit should fail if the tx hasn't completed successfully. > > BTW, I've also seen the transaction timeout that Radim mentioned, but only recently. I wonder if we could do anything to increase it for the stress tests. > Cheers, -- Mircea Markus Infinispan lead (www.infinispan.org) _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

On 11/19/2013 08:48 PM, Mircea Markus wrote: > > On Nov 19, 2013, at 4:49 PM, Dan Berindei <dan.berindei(a)gmail.com&gt; wrote: > >> Is there any reason to use synchronization other than "it's faster"? > > I guess the reason for using synchronization is to invalidate (or updated) an cache. We obviously don't do that ATM, so indeed wondering if there's any point at all... > Pedro any idea? I tried to understand the contract used by Synchronization resources but I didn't find anything concrete. This is what I understood: Synchronization is used as notification for the transaction. The SyncResources are notified that the transaction is going to try to commit. In here, the SyncResources can abort the transaction by invoking transaction.setRollbackOnly() (or similar method). After the first notification, the XaResources tries to commit the transaction and then the SyncResources are notified again with the transaction outcome. In this step, you no longer have the control over the transaction and it is committed/rollbacked. So any fail during the after() will be ignored. Said that, I don't see how synchronization "is faster" than the Xa.

The only use case I see for Synchronization (in Infinispan context) is to cache some computational expensive results. In this case, you may want your system to control the logic (and the transaction, then you enlist it as Xa) but Infinispan is only enlist as Synchronization. If the after() fails, it does not affect the application logic because the transaction is committed and probably, the application may be able to re-calculate it. (probably I'm wrong...) > >> >> IMO, the reasoning for removing synchronizations is the same as item 1 in your proposal, "Async options for commit/rollback". since you are talking about async commit/rollback, I think it can be useful for Synch enlistment. After all, it makes no sense to wait commit/rollback acks since any exception is ignored... wdyt? >> >> >> On Tue, Nov 19, 2013 at 6:35 PM, Mircea Markus <mmarkus(a)redhat.com&gt; wrote: >> >> On Nov 19, 2013, at 4:01 PM, Dan Berindei <dan.berindei(a)gmail.com&gt; wrote: >> >>> Maybe synchronization support is another thing that we should scrap in 7.0, then? >> >> I'd still allow them (sync enlistment is there for a resaon), but have XA+recovery enabled by default and the batching commit should fail if the tx hasn't completed successfully. >> >>> >>> BTW, I've also seen the transaction timeout that Radim mentioned, but only recently. I wonder if we could do anything to increase it for the stress tests. >>> >> >> Cheers, >> -- >> Mircea Markus >> Infinispan lead (www.infinispan.org) >> >> >> >> >> >> _______________________________________________ >> infinispan-dev mailing list >> infinispan-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/infinispan-dev >> >> _______________________________________________ >> infinispan-dev mailing list >> infinispan-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/infinispan-dev > > Cheers, > _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

On 11/21/2013 11:34 AM, Galder Zamarreño wrote: > > > It's way faster actually. The speed difference from all the extra work required by Transaction Manager to deal with multiple XA resources, make transactions recoverable..etc. We've done tests in the past (i.e. Hibernate 2LC) comparing both and the difference was quite big. > you are right. I forgot the recovery mechanism :) _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

On 11/21/2013 03:18 PM, Dan Berindei wrote: > Hmm, couldn't you just disable recovery in the TM to get the same > performance with a XA resource as with a synchronization? If you are suggesting to mess around with the TM, I don't think that is a good idea. First, the TM is external to Infinispan and second you can have others XaResources associated to the TM.

> > > On Thu, Nov 21, 2013 at 1:57 PM, Pedro Ruivo <pedro(a)infinispan.org > <mailto:pedro@infinispan.org>> wrote: > > > > On 11/21/2013 11:34 AM, Galder Zamarreño wrote: > > > > > > It's way faster actually. The speed difference from all the extra > work required by Transaction Manager to deal with multiple XA > resources, make transactions recoverable..etc. We've done tests in > the past (i.e. Hibernate 2LC) comparing both and the difference was > quite big. > > > > you are right. I forgot the recovery mechanism :) > _______________________________________________ > infinispan-dev mailing list > infinispan-dev(a)lists.jboss.org <mailto: infinispan-dev(a)lists.jboss.org&gt; > https://lists.jboss.org/mailman/listinfo/infinispan-dev > > > > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev > _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

On 11/21/2013 05:09 PM, Dan Berindei wrote: On Thu, Nov 21, 2013 at 5:39 PM, Pedro Ruivo <pedro(a)infinispan.org&gt; wrote: > > > On 11/21/2013 03:18 PM, Dan Berindei wrote: > > Hmm, couldn't you just disable recovery in the TM to get the same > > performance with a XA resource as with a synchronization? > > If you are suggesting to mess around with the TM, I don't think that is > a good idea. First, the TM is external to Infinispan and second you can > have others XaResources associated to the TM. > I'm not suggesting that Infinispan should change the TM settings, I'm just wondering if there's a difference between using synchronization in Infinispan and disabling recovery completely (or using an in-memory transaction log) from the user's point of view. Actually, that might be irrelevant if using synchronization can lead to stale locks in Infinispan. If the commit command fails and doesn't release the locks, how will the user be able to find out that there are stale locks and release them? Infinispan detects the failed commit and sends a rollback command. Only if this fails as well, the locks stay unreleased. The problem is just that application thinks it has succeeded while the transaction may have been rolled back (in Infinispan way, the JTA transaction was already committed).

Radim > > > > > > On Thu, Nov 21, 2013 at 1:57 PM, Pedro Ruivo <pedro(a)infinispan.org > > <mailto:pedro@infinispan.org>> wrote: > > > > > > > > On 11/21/2013 11:34 AM, Galder Zamarreño wrote: > > > > > > > > > It's way faster actually. The speed difference from all the extra > > work required by Transaction Manager to deal with multiple XA > > resources, make transactions recoverable..etc. We've done tests in > > the past (i.e. Hibernate 2LC) comparing both and the difference was > > quite big. > > > > > > > you are right. I forgot the recovery mechanism :) > > _______________________________________________ > > infinispan-dev mailing list > > infinispan-dev(a)lists.jboss.org <mailto: > infinispan-dev(a)lists.jboss.org&gt; > > https://lists.jboss.org/mailman/listinfo/infinispan-dev > > > > > > > > > > _______________________________________________ > > infinispan-dev mailing list > > infinispan-dev(a)lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/infinispan-dev > > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev > _______________________________________________ infinispan-dev mailing listinfinispan-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/infinispan-dev -- Radim Vansa <rvansa(a)redhat.com&gt; <rvansa(a)redhat.com&gt; JBoss DataGrid QA _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

On Nov 21, 2013, at 3:18 PM, Dan Berindei <dan.berindei(a)gmail.com&gt; wrote: > Hmm, couldn't you just disable recovery in the TM to get the same performance with a XA resource as with a synchronization? > I don't think that would be enough actually. Even without recovery, for transactions (XA) that have more than one participant registered, the TM writes information on the transaction log. This is a persistent log and writing to it slows down things. > > On Thu, Nov 21, 2013 at 1:57 PM, Pedro Ruivo <pedro(a)infinispan.org&gt; wrote: > > > On 11/21/2013 11:34 AM, Galder Zamarreño wrote: >> >> >> It's way faster actually. The speed difference from all the extra work required by Transaction Manager to deal with multiple XA resources, make transactions recoverable..etc. We've done tests in the past (i.e. Hibernate 2LC) comparing both and the difference was quite big. >> > > you are right. I forgot the recovery mechanism :) > _______________________________________________ > infinispan-dev mailing list > infinispan-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev Cheers, -- Mircea Markus Infinispan lead (www.infinispan.org) _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

On Dec 3, 2013, at 1:26 PM, Mark Little <mlittle(a)redhat.com&gt; wrote: > Why write a log if there is no recovery? That's wrong. AFAIK the recovery is configured as a separate subsystem within the TM. If recovery can be disabled entirely within TM, including TM's log writes, then indeed as Dan suggested, XA resource enlisted would have the same performance as synchronization enlistments. I don't find this setup very nice though :-) > > Mark. > > > On 29 Nov 2013, at 14:39, Mircea Markus wrote: > >> >> On Nov 21, 2013, at 3:18 PM, Dan Berindei <dan.berindei(a)gmail.com&gt; wrote: >> >>> Hmm, couldn't you just disable recovery in the TM to get the same performance with a XA resource as with a synchronization? >>> >> >> I don't think that would be enough actually. Even without recovery, for transactions (XA) that have more than one participant registered, the TM writes information on the transaction log. >> This is a persistent log and writing to it slows down things. >> >> >>> >>> On Thu, Nov 21, 2013 at 1:57 PM, Pedro Ruivo <pedro(a)infinispan.org&gt; wrote: >>> >>> >>> On 11/21/2013 11:34 AM, Galder Zamarreño wrote: >>>> >>>> >>>> It's way faster actually. The speed difference from all the extra work required by Transaction Manager to deal with multiple XA resources, make transactions recoverable..etc. We've done tests in the past (i.e. Hibernate 2LC) comparing both and the difference was quite big. >>>> >>> >>> you are right. I forgot the recovery mechanism :) >>> _______________________________________________ >>> infinispan-dev mailing list >>> infinispan-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >>> >>> _______________________________________________ >>> infinispan-dev mailing list >>> infinispan-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >> >> Cheers, >> -- >> Mircea Markus >> Infinispan lead (www.infinispan.org) >> >> >> >> >> >> _______________________________________________ >> infinispan-dev mailing list >> infinispan-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/infinispan-dev > > --- > Mark Little > mlittle(a)redhat.com > > JBoss, by Red Hat > Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United Kingdom. > Registered in UK and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (USA), Charlie Peters (USA), Matt Parsons (USA) and Brendan Lane (Ireland). > > > > > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev Cheers, -- Mircea Markus Infinispan lead (www.infinispan.org) _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

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,

Hey guys,

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. 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

On Nov 29, 2013, at 1:45 PM, Mark Little <mlittle(a)redhat.com&gt; wrote: > I haven't looked at how ISPN does this today, but here are some thoughts given how we do this within the transaction system for ACID transactions: > > (i) have you considered async prepare? There is a certain degree of asynchronicity in the sense that the prepare we send happens in parallel on all the nodes involved in the transaction. Is this what you have in mind?

> > (ii) async commit/rollback could involve an external audit component to capture the outcome of the transaction, which can be inspected later. Many years ago the OTS and CORBA Notification Service did this together. If the commit/rollback fails this should be picked up by the TM recovery process - I guess that would do the job. This improves the throughput indeed, but might be confusing for users: reading the data written by a "successfully" completed transaction (i.e. TM.commit() returns without exception) would not work.

> > (iii) if you don't allow heuristics then there are guarantees with async commit/rollback. > > Mark. > > > On 8 Nov 2013, at 15:28, Mircea Markus wrote: > >> 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 > > --- > Mark Little > mlittle(a)redhat.com > > JBoss, by Red Hat > Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United Kingdom. > Registered in UK and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (USA), Charlie Peters (USA), Matt Parsons (USA) and Brendan Lane (Ireland). > > > > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev Cheers, -- Mircea Markus Infinispan lead (www.infinispan.org) _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

> Data cannot be read until the transaction has completed (one way or another). So I'm not sure what the problem is you're alluding to here. store.put(k,v1); //initial value tm.begin() store.put(k,v2); tm.commit(); assert store.get(k).equals(v2); //this might fail with async commits, which for some users would be surprising

Even if it doesn't fail: the commit is sent async, the get which is sync might be processed before the commit and sees the old data. On Dec 4, 2013, at 11:09 AM, Mark Little <mlittle(a)redhat.com&gt; wrote: > Agreed if fail. Alternatively it could block whilst waiting for the commit to complete. > > Mark. > > > On 3 Dec 2013, at 13:58, Mircea Markus wrote: > >>> Data cannot be read until the transaction has completed (one way or another). So I'm not sure what the problem is you're alluding to here. >> >> >> store.put(k,v1); //initial value >> tm.begin() >> store.put(k,v2); >> tm.commit(); >> >> assert store.get(k).equals(v2); //this might fail with async commits, which for some users would be surprising > > --- > Mark Little > mlittle(a)redhat.com > > JBoss, by Red Hat > Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United Kingdom. > Registered in UK and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (USA), Charlie Peters (USA), Matt Parsons (USA) and Brendan Lane (Ireland). > > > > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev Cheers, -- Mircea Markus Infinispan lead (www.infinispan.org) _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

Yes, I understand that. My point is that in some environments where async commit is possible they also (opaquely) tie in the read requests to data such that they can block if the commit hasn't completed.

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

On Nov 29, 2013, at 1:46 PM, Mark Little <mlittle(a)redhat.com&gt; wrote: > Why do you think there are no consistency guarantees? Again this may be a difference in the way you use the term 1PC versus how it's used and implemented elsewhere. Indedd, 1PC here has to do with the consensus protocol used by Infinispan internally to update the same data on multiple nodes. Doesn't have to do with the XAResource.commit(xid, isOnePhase) at all (we actually plan to implement that 1PC optimization in the case a single node needs to be updated). > > Mark. > > > On 8 Nov 2013, at 15:28, Mircea Markus wrote: > >> 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 > Cheers, -- Mircea Markus Infinispan lead (www.infinispan.org) _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

On Dec 3, 2013, at 1:29 PM, Mark Little <mlittle(a)redhat.com&gt; wrote: > Oh please tell me your 1PC isn't really 2PC on multiple participants but without a prepare phase?! This is a non-default configuration option which we plan to get rid of in ISPN 7.0. Hence this email :-) > > Mark. > > > On 29 Nov 2013, at 15:59, Mircea Markus wrote: > >> On Nov 29, 2013, at 1:46 PM, Mark Little <mlittle(a)redhat.com&gt; wrote: >> >>> Why do you think there are no consistency guarantees? Again this may be a difference in the way you use the term 1PC versus how it's used and implemented elsewhere. >> >> Indedd, 1PC here has to do with the consensus protocol used by Infinispan internally to update the same data on multiple nodes. Doesn't have to do with the XAResource.commit(xid, isOnePhase) at all (we actually plan to implement that 1PC optimization in the case a single node needs to be updated). Cheers, -- Mircea Markus Infinispan lead (www.infinispan.org) _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

On Dec 4, 2013, at 11:10 AM, Mark Little <mlittle(a)redhat.com&gt; wrote: > So we do have multiple participants within a "1PC" "transaction"? Really? Seriously? Huh? WTF? To clarify this: - this is not exposed as explicit functionality - for a certain configuration, the cache behaves like this (replication is configured *async*) - one of the point of this email thread is disallow this configuration (transactions + *async* replication) Thanks for the feedback. > > Mark. > > > > On 3 Dec 2013, at 14:03, Mircea Markus wrote: > >> >> On Dec 3, 2013, at 1:29 PM, Mark Little <mlittle(a)redhat.com&gt; wrote: >> >>> Oh please tell me your 1PC isn't really 2PC on multiple participants but without a prepare phase?! >> >> This is a non-default configuration option which we plan to get rid of in ISPN 7.0. Hence this email :-) >> >>> >>> Mark. >>> >>> >>> On 29 Nov 2013, at 15:59, Mircea Markus wrote: >>> >>>> On Nov 29, 2013, at 1:46 PM, Mark Little <mlittle(a)redhat.com&gt; wrote: >>>> >>>>> Why do you think there are no consistency guarantees? Again this may be a difference in the way you use the term 1PC versus how it's used and implemented elsewhere. >>>> >>>> Indedd, 1PC here has to do with the consensus protocol used by Infinispan internally to update the same data on multiple nodes. Doesn't have to do with the XAResource.commit(xid, isOnePhase) at all (we actually plan to implement that 1PC optimization in the case a single node needs to be updated). >> >> Cheers, >> -- >> Mircea Markus >> Infinispan lead (www.infinispan.org) >> >> >> >> >> >> _______________________________________________ >> infinispan-dev mailing list >> infinispan-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/infinispan-dev > > --- > Mark Little > mlittle(a)redhat.com > > JBoss, by Red Hat > Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United Kingdom. > Registered in UK and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (USA), Charlie Peters (USA), Matt Parsons (USA) and Brendan Lane (Ireland). > > > > > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev Cheers, -- Mircea Markus Infinispan lead (www.infinispan.org) _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev