On Nov 12, 2013, at 12:56 PM, Galder ZamarreƱo <galder(a)redhat.com> wrote:
On Nov 8, 2013, at 4:28 PM, Mircea Markus <mmarkus(a)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?
Yes
> 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.
yes, the isolation level would 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)
+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
[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
Cheers,
--
Mircea Markus
Infinispan lead (
www.infinispan.org)