On 21 March 2016 at 12:18, Pedro Ruivo <pedro(a)infinispan.org> wrote:
On 03/21/2016 11:19 AM, Sanne Grinovero wrote:
> On 21 March 2016 at 10:07, Pedro Ruivo <pedro(a)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.
That statement is too broad, and proven wrong with real world examples
and practical requirements from our users; in my experience it also is
the primary reason to enable transactions at all.
I'd rather question why this wasn't done than question which use cases
are appropriate, as I don't see what benefit it brings to consider
each cache a different resource? Am I missing a trade-off or is it
fair to say that there are no drawbacks in improving this?
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 :)
>
>>> 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.
it might just be an example, but that doesn't look good enough.
Thanks,
Sanne
>
>>
>> Cheers,
>> Pedro
>>
>>>
>>> Thanks,
>>> Sanne
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> infinispan-dev(a)lists.jboss.org
>>>
https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev(a)lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/infinispan-dev
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev