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

[Dan Berindei]

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...