Whoops, I put Oracle instead of MySQL sorry about that. And to be
more specific, Infinispan RR with Pessimistic locking is like MySQL
RR in that you have non locking repeatable reads with locking writes.
But rereading MySQL docs again I am not sure if it does a db level
snapshot or only read data (haven't worked with it in quite a long
while, let alone RR) [1]
I think I put Oracle on accident since I was thinking about it,
because it doesn't have a RR isolation level :)
Either way I wonder if isolation levels should be named after the SQL
counterparts or have something more specific to their behavior.
Coherence for example [2]
[1]
http://dev.mysql.com/doc/refman/5.6/en/set-transaction.html
[2]
http://docs.oracle.com/cd/E18686_01/coh.37/e18677/api_transactionslocks.h...
On Sun, Sep 22, 2013 at 6:05 AM, Emmanuel Bernard
<emmanuel(a)hibernate.org> wrote:
On 21 sept. 2013, at 18:32, William Burns <mudokonman(a)gmail.com> wrote:
>> [Technically it would be awesome to be able to be able to rely on RR
>> but it doesn't work as in databases - it doesn't snapshot the version
>> of entries not touched yet - so we have to compensate at a higher
>> layer..]
>
> The repeatable read implementation is the same as Oracle using multi
> versioned entries. It sounds like what you are talking about is
> Serializable which doesn't scale
You mean Oracle DB?
Then no I don't think you are correct unless something has changed in this area in
Infinispan. Oracle achieves ANSI RR with snapshot isolation - which offers a contract
between RR and SERIALIZABLE.
But that's not their default isolation level.
Regardless of that my understanding of Infinispan's implementation is that in the
group approach - and I believe FGAM-, I could update different "columns" of the
same "row" - in OGM terms - in parallel provided that the columns are different.
This is not the case of RDBMS RR as I understand it. To work around that your application
must have a version column that you update for each change.
I am a bit rusty on these subjects so feel free to correct me.
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev