[infinispan-dev] rethinking ISPN transactions

[Radim Vansa]

On 11/19/2013 03:06 AM, Mircea Markus wrote:
> On Nov 12, 2013, at 2:51 PM, Paul Ferraro <paul.ferraro at redhat.com> wrote:
>
>> 3. Optimistic tx without Write Skew Check (WSC)
>>> - well, without WSC the transactions are not optimistic by definition
>>> - they are something else: an batch update of multiple key/values. If the batch is successful you know the update was atomic. If it failed you don't get any guarantee
>>> - suggestion: optimistic tx should *always* have WSC enabled (no option to configure it)
>>> - build our batching functionality on top of what currently is optimistic tx without WSC and document it as such
>> OK, but can you elaborate on the last bullet?
>> So, the batching API will no longer contain transactional guarantees?
> The batching API ATM only guarantees that if the commit(end of batch) succeeds everything is applied. If the commit doesn't succeed you get inconsistencies/no guarantees. That's pretty much the kind of guarantees I'd like the new batching to offer.
Are you sure that if commit doesn't fail, the batch is applied? Does 
batching use synchronisation or XA resource enlistment (or, are both 
options possible? In TransactionFactory I see that batching results in 
*_NOXA enum)? Because if it is synchronization and CommitCommand fails 
due to replication timeout, heuristic rollback is applied but the 
application does not receive any kind of exception.

Pardon me if I am mixing things, I am not well educated in all the JTA 
stuff but recently I got pretty surprised that with default settings my 
transaction was rolled back but the app code did not get any failure.

Radim

-- 
Radim Vansa <rvansa at redhat.com>
JBoss DataGrid QA