Caching a callable statement is presumably just as much a good idea as
caching a prepared statement: however only prepared statements are used in
jaws, so the effect is more noticable with cmp.
I don't have a db with all these kinds of resultsets. If you test this out
and submit a patch (preferably against rabbithole) and no one objects I'll
commit it (to rabbithole).
david jencks
On 2001.08.23 08:52:17 -0400 Daniel CAUNE wrote:
> 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
>
>
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
