[infinispan-dev] XA transactions on a single CacheManager?

[Radim Vansa]

On 03/21/2016 01:18 PM, Pedro Ruivo wrote:
>
> On 03/21/2016 11:19 AM, Sanne Grinovero wrote:
>> On 21 March 2016 at 10:07, Pedro Ruivo <pedro at infinispan.org> wrote:
>>> Hi Sanne
>>>
>>> On 03/15/2016 07:22 PM, Sanne Grinovero wrote:
>>>> Hi all,
>>>>
>>>> I just noticed that when I'm making changes to multiple caches within
>>>> the same transaction, the transaction manager will treat this as XA
>>>> transactions.
>>>>
>>>> That seems suboptimal as they are all managed by the same resource; is
>>>> there a configuration I'm missing or should I open a JIRA to ask for
>>>> an improvement?
>>> what are you suggesting? Having a single XA resource per cache manager
>>> instead of one per cache?
>> Yes, I actually expected that to be the case already.
>> Would that be complex? I am not familiar at all with this code, I was
>> just surprised as I don't see why it is the way it is: I don't need XA
>> transactions when writing to multiple tables on a same RDBMs ;)
>>
>> My guess is that we originally thought of Caches a being used mostly
>> independently, but I think experience is telling us differently.
> It makes sense since the tables in RDBMs has some kind of relation
> between them. Caches on other hand, they haven't.

We don't offer any constraints as RDBMs have, but as columns in RDBMs 
contain FKs to row in another table, I would expect that data in cache 
also often contains keys for other caches/ keys into the same cache. 
Either app-driven, or automatically generated (as OGM probably does). 
It's not just OGM, values in entity collection cache in ORM 2LC contains 
list of keys in entity cache.

>
> It will not be impossible to move the XA to the cache manager, although,
> it would add some complexity to our xa implementation. Randim already
> opened a JIRA.
>
> It would be good to know if someone has any issue with the
> per-cache-manager xa :)

Do you expect that people dig as deep as Sanne, check and complain in 
JIRA? IMO at best, they get surprised when they find out, expect this to 
be the intent and workaround that.

Radim

>
>>>> I'm not just asking for performance reasons: having to setup a
>>>> transaction manager is an annoying configuration step for Java SE
>>>> users.
>>> I got a little confused by this. You can use the same transaction
>>> manager in all the caches, so you have to configured it once.
>>> If you don't have one, you could use the DummyTransactionManager (we
>>> need to rename it!) in the core that contains the basic to handle
>>> transactions.
>> To support XA transactions the transaction manager requires both a
>> different configuration
>> and different dependencies.
>>
>> I noticed while working on a "Getting started with Hibernate OGM"
>> which needs to be simple of course,
>> and this example happens to use Infinispan.
>> Since we need writes on multiple caches, this makes the setup phase of
>> the tutorial much harder, to the point that I'm considering to simply
>> switch to something like MongoDB so that I can keep the OGM tutorial
>> focused.
> Even if you have a per-cache-manager xa, you still have to configure the
> TransactionManager.
>
> If you don't want to complicate the "getting start" you could use the
> DummyTransactionManager to achieve the same result. In infinispan, you
> only need to set the "transaction-manager-lookup" in <transaction> tag
> to fetch the DummyTransactionManager.
>
>>> Cheers,
>>> Pedro
>>>
>>>> Thanks,
>>>> Sanne
>>>> _______________________________________________
>>>> 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
>> _______________________________________________
>> 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


-- 
Radim Vansa <rvansa at redhat.com>
JBoss Performance Team