On Nov 8, 2013, at 4:28 PM, Mircea Markus <mmar...@redhat.com> 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@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Galder Zamarreño gal...@redhat.com twitter.com/galderz Project Lead, Escalante http://escalante.io Engineer, Infinispan http://infinispan.org _______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
