Re: Re: JDBC Performance

From: Gunnar R|nning <gunnar(at)candleweb(dot)no>
To: "Keith L(dot) Musser" <kmusser(at)idisys(dot)com>
Cc: "Gunnar R|nning" <gunnar(at)candleweb(dot)no>, "PGSQL-General" <pgsql-general(at)postgresql(dot)org>
Subject: Re: Re: JDBC Performance
Date: 2000-09-29 17:35:39
Message-ID: x6g0mjdrtg.fsf@thor.candleweb.no
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-jdbc

[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.

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

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Mitch Vincent 2000-09-29 17:46:13 Re: Fw: Redhat 7 and PgSQL
Previous Message Adam Lang 2000-09-29 17:34:36 Re: Fw: Redhat 7 and PgSQL

Browse pgsql-jdbc by date

  From Date Subject
Next Message Peter Mount 2000-10-02 10:50:10 Re: Re: JDBC Performance
Previous Message Gunnar R|nning 2000-09-29 17:06:27 Re: Re: JDBC Performance