Re: Re: JDBC Performance

On 29 Sep 2000, Gunnar R|nning wrote:

> [feel stupid replying to myself...]
>
> Gunnar R|nning <gunnar(at)candleweb(dot)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.

Our concurrency is done by locking against the pg_Stream object. As there
is only one per connection this works (as it prevents the network protocol
from getting messed up).

The pool of free byte arrays don't need to be locked in this way. As I see
it, we would need a single static class that holds two stacks, one of free
arrays, and the other of arrays in use. The methods used to move an array
from one stack to another need to be syncronized so they are atomic.

The only thing to think of here, is how to deal in reaping arrays that are
no longer used, but who's Connection's have died abnormally.

> 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().

Some people don't call close() unfortunately. Bad practice as you
should. I like this idea as it keeps things simple in the source - the
close() methods are supposed to free up any resources used, and this is
what's being done.

> Pros: Faster for the typical web application that uses pooled connections,
> because this approach would require less synchronization.
> Cons: Higher memory consumption.

How many people use pooled connections? I don't, but then most of my Java
stuff is application based, not web/servlet based.

Approach 1 does have some advantages for pooled connections but would be a
problem for users who use single connections per VM. Even worse, would be
those using applets (some still use JDBC direct from applets), and the
limiting factor there is the size of the driver.

> Either of these two approaches would probably require some reorganization
> of how the driver works.

Anything of this nature always does.

Peter

--
Peter T Mount peter(at)retep(dot)org(dot)uk http://www.retep.org.uk
PostgreSQL JDBC Driver http://www.retep.org.uk/postgres/
Java PDF Generator http://www.retep.org.uk/pdf/