[infinispan-dev] rethinking ISPN transactions

[Pedro Ruivo]

On 11/19/2013 08:48 PM, Mircea Markus wrote:
>
> On Nov 19, 2013, at 4:49 PM, Dan Berindei <dan.berindei at gmail.com> wrote:
>
>> Is there any reason to use synchronization other than "it's faster"?
>
> I guess the reason for using synchronization is to invalidate (or updated) an cache. We obviously don't do that ATM, so indeed wondering if there's any point at all...
> Pedro any idea?

I tried to understand the contract used by Synchronization resources but 
I didn't find anything concrete.

This is what I understood: Synchronization is used as notification for 
the transaction. The SyncResources are notified that the transaction is 
going to try to commit. In here, the SyncResources can abort the 
transaction by invoking transaction.setRollbackOnly() (or similar 
method). After the first notification, the XaResources tries to commit 
the transaction and then the SyncResources are notified again with the 
transaction outcome. In this step, you no longer have the control over 
the transaction and it is committed/rollbacked. So any fail during the 
after() will be ignored.

Said that, I don't see how synchronization "is faster" than the Xa. The 
only use case I see for Synchronization (in Infinispan context) is to 
cache some computational expensive results. In this case, you may want 
your system to control the logic (and the transaction, then you enlist 
it as Xa) but Infinispan is only enlist as Synchronization. If the 
after() fails, it does not affect the application logic because the 
transaction is committed and probably, the application may be able to 
re-calculate it. (probably I'm wrong...)

>
>>
>> IMO, the reasoning for removing synchronizations is the same as item 1 in your proposal, "Async options for commit/rollback".

since you are talking about async commit/rollback, I think it can be 
useful for Synch enlistment. After all, it makes no sense to wait 
commit/rollback acks since any exception is ignored... wdyt?

>>
>>
>> On Tue, Nov 19, 2013 at 6:35 PM, Mircea Markus <mmarkus at redhat.com> wrote:
>>
>> On Nov 19, 2013, at 4:01 PM, Dan Berindei <dan.berindei at gmail.com> wrote:
>>
>>> Maybe synchronization support is another thing that we should scrap in 7.0, then?
>>
>> I'd still allow them (sync enlistment is there for a resaon), but have XA+recovery enabled by default and the batching commit should fail if the tx hasn't completed successfully.
>>
>>>
>>> BTW, I've also seen the transaction timeout that Radim mentioned, but only recently. I wonder if we could do anything to increase it for the stress tests.
>>>
>>
>> Cheers,
>> --
>> Mircea Markus
>> Infinispan lead (www.infinispan.org)
>>
>>
>>
>>
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> Cheers,
>