cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Torsten Curdt <>
Subject Re: big ESQL performance problem - this one's weird
Date Tue, 04 Mar 2003 18:27:28 GMT
> Ooops. Torsten, I believe this changed with your refactoring, right?
> (2.0.5 still uses plain statements in this case) Any idea why you have
> changed this? (OK, PreparedStatements do have advantages, but)

Yes, I did. IIRC it lead to a much easier handling inside the classes.
And due to the reported SQL injection I wanted to have as least "simple"
Statements inside the codebase as possible.

The problem is: the PreparedStatment vs Statement issue is very 
controversial. Especially if you do not reuse the same PreparedStatment 
object. Speed advantage or disadvantage seem to vary from database to 

In general you often get the advice [1] to always use Prepared 
Statements. But some people are reporting it to be slower - others that 
it's faster. So whom shall we kick in the but? Database A user or 
database B user? Of course we could make it... configurable *ring* *ring*

IMO it is not cocoon's job to use the best method for each individual 
database only because the database engine and/or the driver does not do 
"this" or "that" internally. (Why not file a bug against the driver/db?)

I mean we *could* think about some sort of database capabilites 
database... (weird name;) some sort of an abstraction thing. Chris, you 
remember? I was talking about merging the database abstraction from esql 
and the database modules. That could be the first step ...but I don't 
really know if we really should follow that path.

I mean: JDBC is already supposed to be some kind of database 
abstraction. Well, supposed...

Anyway, Leszek, could you please check with the same ResultSet type
as in the JdbcEsqlQuery?

I removed the Statements - so I'll try to help you get this fixed - 
anyhow :)



View raw message