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 database.
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 (ResultSet.TYPE_SCROLL_INSENSITIVE,ResultSet.CONCUR_READ_ONLY) as in the JdbcEsqlQuery?
I removed the Statements - so I'll try to help you get this fixed - anyhow :)
cheers -- Torsten
[1] http://www.javaperformancetuning.com/tips/jdbc.shtml
