Arndt,
+1 for doing PreparedStatement caching. No objections here, provided the
criteria mentioned by Holger are satisfied. Please provide us with patches
once you have this working. Even if this happens after Beta 1, I will give
my +1 for adding this to Beta X.
Just want to make sure I understand all the implications:
1. From what I understand, PreparedStatements are inseparable from their
originating Connection object, generally you can't run it via a different
connection (though I think Oracle 9i has some provisions for that?). So in
a big connection pool cache will take some time for it to warm up, since
connections are handed out randomly.
2. Implementing PreparedStatement pooling inside Connection wrapper means
that non-Cayenne DataSources will not have this feature. This is fine with
me (those DataSources may actually implement caching on their own), just
wanted to point this out.
Andrus
> Andrus Adamchik wrote:
>
>> One pending issue right now is inheritance. Andriy, are you done with
>> the piece you were working on? There is also an inheritance patch from
>> Arndt, but I am hesitant to delay Beta because of that. I will look at
>> what we can do about it
> ...
>> A few things for Beta
>> 1. API freeze.
>> 2. Modeler catching up with the core framework.
>> 3. Bug Fixing, documentation, examples.
>
> Hi Andrus,
>
> I think I can live with beta not handling inheritance,
> my patch for that isn't too big, so I can synchronize it
> (but it still doesn't pass the unit test...)
>
> More important for me and for my position in proposing
> cayenne internally is performance. I understand and
> support your attitude of postponing performance tuning,
> but maybe for a start we can get prepared statement caching
> into beta?
> This is a precondition for any serious profiling and
> my second essential patch.
>
> I could work on streamlining that and make it pass
> the unit tests, if you signal your support.
>
> best regards,
>
> Arndt
This archive was generated by hypermail 2.0.0 : Thu Mar 27 2003 - 10:52:17 EST