On 2 Oct 2000, Gunnar R|nning wrote:
> Peter Mount <peter@retep.org.uk> writes:
>
> > 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.
>
> I agree that a global stack for free byte arrays could be preferable, as
> long synchronization doesn't add to much overhead. But because of the
> problem you mention with connections dying abnormally or other error
> situtations we need to store the used byte arrays in a place where that
> allows the garbage collector to cleanup after us. I think the ResultSet
> or Statement would be the right place to store these.
>
> >
> > 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.
>
> Pooled connections are very common in the web world, but I would think that
> it makes sense for many applications to reuse connections as well. Maybe I
> should add some configuration parameters, so the user can tune the
> implementation or even choose implementation to suite a particular
> application ?
The best place for this is in org.postgresql.Driver, as that's where you
can add the DriverParameter's code (some old stubs exist, under there
commented out). We must also look at the javax.sql stuff to see how its
done there also.
Peter
--
Peter T Mount peter@retep.org.uk http://www.retep.org.uk
PostgreSQL JDBC Driver http://www.retep.org.uk/postgres/
Java PDF Generator http://www.retep.org.uk/pdf/