[infinispan-dev] rethinking ISPN transactions

[Mircea Markus]

On Nov 12, 2013, at 1:26 PM, Radim Vansa <rvansa at redhat.com> 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 Markus
Infinispan lead (www.infinispan.org)