[feel stupid replying to myself...]
Gunnar R|nning <gunnar@candleweb.no> writes:
> > at org.postgresql.jdbc2.ResultSet.getObject(ResultSet.java:789)
>
> OK, I found the problem. I will post a fixed version later today. The
> problem was that getObject() executed Field.getSQLType() which in turn
> executed Connection.ExecSQL(). I modified ExecSQL to deallocate the cached
> byte arrays on entry, because I believed it only were called by
> Statement.execute() methods. I guess I should move the deallocation into
> the Statement classes instead, as that is were it really belongs.
>
> I interpret the JDBC spec. to say that only one ResultSet will be open
> per. Statement, but one Connection canm have several statements with one
> result set each.
>
This does of course imply that arrays should be cached on a
ResultSet/Statement basis instead of on PGStream as it is done now. Do
anybody have good suggestions on how to implement this ?
Approach 1:
The cache is now only per Connection, maybe we should a global pool of free
byte arrays instead ?
Cons :
This would probably mean that we need to add more
synchronization to ensure safe access by concurrent threads and could
therefore lead to poorer performance and concurrency.
Pros : Possibly lower memory consumption and higher performance in some
cases(when you find free byte arrays in the global pool). If your
application is not pooling connections, but recreating connections it would
also benefit performance wise from this approach.
Approach 2:
Another solution would be have the cache be per connection but associate a
pool of used byte arrays to each resultset/statement and deallocate these
on resultset.close()/statement.close().
Pros: Faster for the typical web application that uses pooled connections,
because this approach would require less synchronization.
Cons: Higher memory consumption.
Either of these two approaches would probably require some reorganization
of how the driver works.
Any other suggestions or comments ?
Regards,
Gunnar
