On Nov 12, 2013, at 3:09 PM, Radim Vansa <rvansa(a)redhat.com> wrote:
On 11/12/2013 02:46 PM, Mircea Markus wrote:
> On Nov 12, 2013, at 1:26 PM, Radim Vansa <rvansa(a)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(a)redhat.com>
JBoss DataGrid QA
_______________________________________________
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)