[infinispan-dev] rethinking ISPN transactions

[Radim Vansa]

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? Can writeSkewCheck be used with pessimistic 
transactions?

>
> [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