12:39 p.m.
Read and share :)
http://martingencur.blogspot.com/
Cheers
--
Martin Gencur
--
QA Engineer, JBoss Data Grid
Desk phone: +420 532 294 192, ext. 62192
12:56 p.m.
Tweeted.
On 05/23/2012 12:39 PM, Martin Gencur wrote:
Read and share :)
http://martingencur.blogspot.com/
Cheers
1:06 p.m.
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?
On 23 May 2012 18:56, Prabhat Jha <pjha(a)redhat.com> wrote:
Tweeted.
On 05/23/2012 12:39 PM, Martin Gencur wrote:
> Read and share :)
>
> http://martingencur.blogspot.com/
>
> Cheers
>
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
2:31 p.m.
On Wed, May 23, 2012 at 9:06 PM, Sanne Grinovero <sanne(a)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.
On 23 May 2012 18:56, Prabhat Jha <pjha(a)redhat.com> wrote:
> Tweeted.
>
> On 05/23/2012 12:39 PM, Martin Gencur wrote:
>> Read and share :)
>>
>> http://martingencur.blogspot.com/
>>
>> Cheers
>>
> _______________________________________________
> 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
2:37 p.m.
Dan Berindei píše v Wed 23. 05. 2012 v 22:31 +0300:
On Wed, May 23, 2012 at 9:06 PM, Sanne Grinovero
<sanne(a)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
Thanks for explaining it instead of me ;-)
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.
That's a good idea, I'll add this to the article. Thanks
> On 23 May 2012 18:56, Prabhat Jha <pjha(a)redhat.com> wrote:
>> Tweeted.
>>
>> On 05/23/2012 12:39 PM, Martin Gencur wrote:
>>> Read and share :)
>>>
>>> http://martingencur.blogspot.com/
>>>
>>> Cheers
>>>
>> _______________________________________________
>> 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
--
Martin Gencur
--
QA Engineer, JBoss Data Grid
Desk phone: +420 532 294 192, ext. 62192
2:02 a.m.
On 05/23/2012 09:31 PM, Dan Berindei wrote:
On Wed, May 23, 2012 at 9:06 PM, Sanne
Grinovero<sanne(a)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...
Tristan
2:08 a.m.
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(a)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?
Tristan
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Martin Gencur
--
QA Engineer, JBoss Data Grid
Desk phone: +420 532 294 192, ext. 62192
2:09 a.m.
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(a)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.
Tristan
3:24 a.m.
On Thu, May 24, 2012 at 10:09 AM, Tristan Tarrant <ttarrant(a)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(a)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...
5:11 a.m.
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(a)gmail.com> wrote:
On Thu, May 24, 2012 at 10:09 AM, Tristan Tarrant
<ttarrant(a)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(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
1:06 p.m.
Congrats on your first blog Martin. I hope to see many more of these now.
On 05/23/2012 12:56 PM, Prabhat Jha wrote:
Tweeted.
On 05/23/2012 12:39 PM, Martin Gencur wrote:
> Read and share :)
>
> http://martingencur.blogspot.com/
>
> Cheers
>
5:17 a.m.
Thanks Martin for writing that up!
We wanna be driving traffic towards infinispan.blogspot.com, so could you please repost it
there too? Please send me your google account id and I'll add you as poster.
For future posts, IMO, these should be posted direcly in infinispan.blogspot.com, what do
others think?
We have a blog for a reason…
Cheers,
On May 23, 2012, at 7:39 PM, Martin Gencur wrote:
Read and share :)
http://martingencur.blogspot.com/
Cheers
--
Martin Gencur
--
QA Engineer, JBoss Data Grid
Desk phone: +420 532 294 192, ext. 62192
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
5:26 a.m.
On 24 May 2012 11:17, Galder Zamarreño <galder(a)redhat.com> wrote:
Thanks Martin for writing that up!
We wanna be driving traffic towards infinispan.blogspot.com, so could you please repost
it there too? Please send me your google account id and I'll add you as poster.
For future posts, IMO, these should be posted direcly in infinispan.blogspot.com, what do
others think?
+1
What about my occasional mention of Infinispan on in.relation.to ? I'd
keep it there, as it reminds existance of Infinispan to a different
audience.
I wrote one yesterday, which was maybe more suited for
infinispan.blogspot.com ; still I think it was better on
in.relation.to but have no strong idea about why.
We have a blog for a reason…
Cheers,
On May 23, 2012, at 7:39 PM, Martin Gencur wrote:
> Read and share :)
>
> http://martingencur.blogspot.com/
>
> Cheers
>
> --
> Martin Gencur
> --
> QA Engineer, JBoss Data Grid
> Desk phone: +420 532 294 192, ext. 62192
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
5:38 a.m.
On 24 May 2012, at 11:26, Sanne Grinovero wrote:
On 24 May 2012 11:17, Galder Zamarreño <galder(a)redhat.com>
wrote:
> Thanks Martin for writing that up!
>
> We wanna be driving traffic towards infinispan.blogspot.com, so could you please
repost it there too? Please send me your google account id and I'll add you as
poster.
>
> For future posts, IMO, these should be posted direcly in infinispan.blogspot.com,
what do others think?
+1
What about my occasional mention of Infinispan on in.relation.to ? I'd
keep it there, as it reminds existance of Infinispan to a different
audience.
I wrote one yesterday, which was maybe more suited for
infinispan.blogspot.com ; still I think it was better on
in.relation.to but have no strong idea about why.
It would depend on a case by case basis. If unsure, email
infinispan-core-dev(a)infinispan.org :)
--
Manik Surtani
manik(a)jboss.org
twitter.com/maniksurtani
Lead, Infinispan
http://www.infinispan.org
8:19 a.m.
On May 24, 2012, at 12:38 PM, Manik Surtani wrote:
On 24 May 2012, at 11:26, Sanne Grinovero wrote:
> On 24 May 2012 11:17, Galder Zamarreño <galder(a)redhat.com> wrote:
>> Thanks Martin for writing that up!
>>
>> We wanna be driving traffic towards infinispan.blogspot.com, so could you please
repost it there too? Please send me your google account id and I'll add you as
poster.
>>
>> For future posts, IMO, these should be posted direcly in infinispan.blogspot.com,
what do others think?
>
> +1
> What about my occasional mention of Infinispan on in.relation.to ? I'd
> keep it there, as it reminds existance of Infinispan to a different
> audience.
> I wrote one yesterday, which was maybe more suited for
> infinispan.blogspot.com ; still I think it was better on
> in.relation.to but have no strong idea about why.
It would depend on a case by case basis. If unsure, email
infinispan-core-dev(a)infinispan.org :)
Also, if unsure, you can always post it twice, i.e. to both in.relation.to and
infinispan.blogspot.com :)
--
Manik Surtani
manik(a)jboss.org
twitter.com/maniksurtani
Lead, Infinispan
http://www.infinispan.org
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
5:50 a.m.
Galder Zamarreño píše v Thu 24. 05. 2012 v 12:17 +0200:
Thanks Martin for writing that up!
We wanna be driving traffic towards infinispan.blogspot.com, so could you please repost
it there too? Please send me your google account id and I'll add you as poster.
Sure, no problem. I'm using martin.gencur(a)gmail.com . Let me know when I
have the rights.
Thanks
For future posts, IMO, these should be posted direcly in
infinispan.blogspot.com, what do others think?
We have a blog for a reason…
Cheers,
On May 23, 2012, at 7:39 PM, Martin Gencur wrote:
> Read and share :)
>
> http://martingencur.blogspot.com/
>
> Cheers
>
> --
> Martin Gencur
> --
> QA Engineer, JBoss Data Grid
> Desk phone: +420 532 294 192, ext. 62192
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Martin Gencur
--
QA Engineer, JBoss Data Grid
Desk phone: +420 532 294 192, ext. 62192
4375
days inactive
4376
days old
infinispan-dev@lists.jboss.org
15 comments
7 participants
participants (7)
-
Dan Berindei -
Galder Zamarreño -
Manik Surtani -
Martin Gencur -
Prabhat Jha -
Sanne Grinovero -
Tristan Tarrant