Hi,
Jason Rasmussen gave some clues about my JDBC problem (I not able to use
the method last for example), and I finally find that the problem comes
from org.jboss.pool.connector.jdbc.ConnectionInPool:
(...)
public PreparedStatement prepareStatement( String sql, int
resultSetType, int resultSetConcurrency )
throws SQLException {
return prepareStatement( sql );
}
(...)
Why are the two parameters resultSetType and resultSetConcurrency
omitted ?
I suppose this limitation comes from the PreparedStatement cache object
of a PreparedStatement, a LeastRecentlyUsedCache object; the key of a
PreparedStatement cache is its SQL string:
"PreparedStatement ps = ( PreparedStatement
)preparedStatementCache.useObject( sql );"
Two PreparedStatement objects are quite different if they have been
created with two kind of result set and concurrency type, even if they
have the same SQL string. Because the PreparedStatement cache object
doesn't contain the options of a PreparedStatement (its type is a
strnig), I understand we can't cache a PreparedStatement object
initialized with other options than default.
But I think this limitation is not really acceptable. Why don't we use
another key object as follows?
public class PreparedStatementCacheKey {
private int resultSetType;
private int resultSetConcurrency;
private String sql;
public PreparedStatementCacheKey( String sql ) {
this.sql = sql;
// Result sets created using the returned PreparedStatement will
// have forward-only type and read-only concurrency, by default,
// (we respect here the Interface Connection documentation).
resultSetType = ResultSet.TYPE_FORWARD_ONLY
resultSetConcurrency = ResultSet.CONCUR_READ_ONLY;
}
public PreparedStatementCacheKey( String sql, int resultSetType, int
resultSetConcurrency ) {
this.sql = sql;
this.resultSetType = resultSetType;
this.resultSetConcurrency = resultSetConcurrency;
}
public boolean equals( Object obj ) {
if (this == obj) return true;
else if (!obj instanceof PreparedStatementCacheKey) return false;
PreparedStatementCacheKey psck = (PreparedStatementCacheKey)obj;
return sql.equals(psck.getSql()) &&
resultSetType==psck.getResultSetType() &&
resultSetConcurrency = psck.getResultSetConcurrency();
}
public String getSql() {
return sql;
}
public int getResultSetType() {
return resultSetType;
}
public int getResultSetConcurrency() {
return resultSetConcurrency;
}
}
On another hand, why do we need to cache a prepared statement while we
don't cache a callable statement?
Do you plan to fix this problem soon?
Regards,
Daniel
On jeu, 2001-08-23 at 10:27, Peter Fagerlund wrote:
> on 1-08-23 09.37, Daniel CAUNE at [EMAIL PROTECTED] wrote:
> > I have read Minerva code will be maintained externally. Where can I find
> > the source of Minerva used by JBoss (minerva-1_0b3.jar) ?
>
> module jbosspool in CVS or here : http://jboss.org/zip_archives/
>
>
> _______________________________________________
> JBoss-user mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/jboss-user
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
