On Nov 19, 2013, at 7:46 AM, Radim Vansa <rvansa(a)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(a)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(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)