Re: Re: JDBC Performance

Peter Mount <peter(at)retep(dot)org(dot)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 ?

Regards,

Gunnar