[infinispan-dev] rethinking ISPN transactions

[Mircea Markus]

On Nov 12, 2013, at 3:09 PM, Radim Vansa <rvansa at redhat.com> wrote:

> On 11/12/2013 02:46 PM, Mircea Markus wrote:
>> 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.
> 
> It's not just about optimistic vs pessimistic - this is pretty well 
> documented, I think. The problem is how this interacts with async modes 
> (when I have pess. txs and execute put, when is the lock acquired?), 1pc 
> stuff (even if we're going to remove it in 7.0, I'd like to have it 
> documented for 6.0).
> Return values for various operations are another thing - the document 
> should mention that we can get anything as the return value
> and the 
> write skew check verifies that we're overwriting the same value as we've 
> read - actually, does it hold that with pess txs put always returns the 
> actually overwritten value?

in 7.0 we might just use explicit methods in order to return values:
put(K,V): void
putAndGet(K,V):V
Indeed the second one implies a read on V and should fail WSC.

> Can writeSkewCheck be used with pessimistic 
> transactions?

No

> 
>> 
>> [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,
> 
> 
> -- 
> Radim Vansa <rvansa at redhat.com>
> JBoss DataGrid QA
> 
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

Cheers,
-- 
Mircea Markus
Infinispan lead (www.infinispan.org)