From: | Dave Cramer <pg(at)fastcrypt(dot)com> |
---|---|
To: | Kris Jurka <books(at)ejurka(dot)com> |
Cc: | Josh Berkus <josh(at)agliodbs(dot)com>, Heikki Linnakangas <heikki(at)enterprisedb(dot)com>, pgsql-jdbc(at)postgresql(dot)org |
Subject: | Re: Caching driver on pgFoundry? |
Date: | 2007-09-05 18:20:31 |
Message-ID: | 159CA908-A763-4FB0-824F-8DCF3A3DD22C@fastcrypt.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-jdbc |
On 5-Sep-07, at 2:12 PM, Kris Jurka wrote:
>
>
> On Wed, 5 Sep 2007, Dave Cramer wrote:
>
>>
>> On 5-Sep-07, at 1:27 PM, Kris Jurka wrote:
>>
>>> But that benchmark was run with a different caching
>>> implementation than the wrapper version, so I'm not sure how
>>> that's relevant. When Sun chose to use unpublished and
>>> unreviewed code for the benchmark they got themselves in a little
>>> bind and I'm not sure it's our job to bail them out by publishing
>>> and advertising code that we're not confident in. Heikki,
>>> Oliver, and myself did not believe the code used by Sun in the
>>> benchmark was correct in the general case so it was rejected for
>>> inclusion in the core driver.
>>
>> So as I understand it the objection to the caching implementation
>> is that statement caching belongs in the app server ?
>
> No, the objection above is that the code you originally submitted
> was not good enough to be included in the driver regardless of
> whether it should be in the driver or app server. If we aren't
> using the code that you originally submitted then the argument that
> we need to publish something for benchmark compliance is silly
> because the requirement is you publish the code/driver used, not a
> somewhat similar implementation.
As I recall the events. The only objection to code that I submitted
for inclusion was Heikki's objection as to where caching belonged.
The proof of concept code was clearly not production and was not
meant for inclusion it was meant to generate this argument. As nobody
argued vehemently at the time I went ahead with a production version.
>
>> If this is the case then I would argue that having caching in the
>> appserver is a great idea for everyone using an appserver it does
>> not help the rest of the world that doesn't use an app server.
>
> This is the consensus I'd like to see built before we spend a lot
> of time on something. Heikki doesn't believe we should do this at
> all as it is covered by DBCP and app server pools.
Well DBCP has it's issues. It is very large and not the fastest piece
of code in the world.
> You clearly believe we need this and I'm sort of on the fence (I
> recall that's where Oliver is as well, but I don't claim to speak
> for him).
So we basically have one nay vote holding this up ?
Dave
>
>> Is there a technical argument here ?
>>
>
> No, this is just a recap of the previous events from my perspective.
>
> Kris Jurka
From | Date | Subject | |
---|---|---|---|
Next Message | Kris Jurka | 2007-09-05 18:25:18 | Re: Caching driver on pgFoundry? |
Previous Message | Kris Jurka | 2007-09-05 18:12:39 | Re: Caching driver on pgFoundry? |