[infinispan-dev] rethinking ISPN transactions

[Mircea Markus]

On Nov 19, 2013, at 7:46 AM, Radim Vansa <rvansa at redhat.com> wrote:

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

good point, so with current batching, the batch might fail and you're not even notified about that.

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

this is quite a subtle aspect of JTA transactions (is Synchronisation.afterCompletion failures are not propagated to the user) - you have a very good point here, thanks!

> 
> Radim
> 
> -- 
> 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)