Re: [infinispan-dev] rethinking ISPN transactions
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.
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(a)redhat.com>
JBoss DataGrid QA