[infinispan-dev] How to configure Infinispan with transactions, backed by relational DB on JBoss AS 7 vs. Tomcat 7 ?

[Sanne Grinovero]

Thanks for all clarifications, I wasn't aware of these problems.

I hope we won't need c3p0 in the longer term, it starts such a pile of
threads and I always had long fights to have it shut up all the
warnings it logs in many "doubtful but valid" use cases :-/
Not saying that's wrong as we can guess many good reasons, but since
we have the same service already from the container it's a waste of
resources.

On 24 May 2012 09:24, Dan Berindei <dan.berindei at gmail.com> wrote:
> On Thu, May 24, 2012 at 10:09 AM, Tristan Tarrant <ttarrant at redhat.com> wrote:
>> On 05/24/2012 09:08 AM, Martin Gencur wrote:
>>> Tristan Tarrant píše v Thu 24. 05. 2012 v 09:02 +0200:
>>>> On 05/23/2012 09:31 PM, Dan Berindei wrote:
>>>>> On Wed, May 23, 2012 at 9:06 PM, Sanne Grinovero<sanne at infinispan.org>   wrote:
>>>>>> Nice work Martin!
>>>>>>
>>>>>> Just one doubt, especially since it's a rather long post.. why would
>>>>>> someone want to use c3p0 on AS7 ? Isn't the included datasource pool
>>>>>> far superior?
>>>>>>
>>>>> The AS7 datasource tries to join the cache transaction, but that won't
>>>>> work because it's too late (we only write to the cache store during
>>>>> commit). Martin alluded to that problem, but he wasn't very specific -
>>>>> he just pointed at https://issues.jboss.org/browse/ISPN-604
>>>>>
>>>>> Martin, I think it would have been best if you listed the error
>>>>> message as well so any users having the same problem can find your
>>>>> post.
>>>>>
>>>> Actually since the inclusion of ISPN-2040 in master, 5.1.x and JDG, that
>>>> is not strictly true anymore...
>>> Not strictly but still true, right? What happens when there is a
>>> transaction and it rolls back? Will the entry be removed back from the
>>> cache store? If yea, why is this marked as workaround?
>> It doesn't actually implement proper transactional behaviour. It's just
>> that the error may not be there anymore.
>>
>
> Huh, I missed ISPN-2040... I have added a link from ISPN-604 in case I
> forget again ;)
>
> Martin, the write to the cache store is during the commit phase, the
> transaction couldn't be rolled back at that point anyway.
>
> The problem is the other way around, if the DB write fails, it's too
> late for us to roll back the cache transaction - so the DB error will
> be ignored. This issue remains, whether you use a managed datasource
> with the ISPN-2040 fix or c3p0 without the fix (and in some use cases
> it might actually be the desired behaviour).
>
> If we could avoid the tx suspend/resume around the cache store write
> by using c3p0, I think it would still be worth replacing the
> AF7-built-in  datasource. But it looks like the "hack" is active all
> the time...
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev