I forgot to add that you now need concurrent.jar from the src/lib directory
and that you can set all the connection parameters in near-native form
using the DefaultConnectionRequestInfo property.

FBConnectionRequestInfo essentially contains a dpb (database parameter
block). You can set anything belonging in a dpb by calling
cri.setProperty(int type, String content)
cri.setProperty(int type)
cri.setProperty(int type int content)
0r
cri.setProperty(int type byte[] content)

where type is the gds constant for the property you are interested in, and
the content is as appropriate for that type.

Thanks
david jencks

On 2002.01.05 00:56:10 -0500 David Jencks wrote:
> I added built in pooling to the FBWrappingDataSource in the all-java
> driver.
>
> To use it, create an FBWrappingDataSource, and configure the
>
> MinSize
> MaxSize
> BlockingTimeout (milliseconds) or LoginTimeout (seconds)
> IdleTimeout (milliseconds) or IdleTimeoutMinutes (minutes)
> Pooling = true
>
> When you request your first connection, the pooling mechanism will start
> up. After the first connection for a given user is returned, the pool
> will
> create more connections up to minSize.
>
> There is a separate pool for each user you request connections for.
>
> The IdleTimeout feature works like this: there is a thread that looks for
> timed out connections, that runs every IdleTimeout/2 milliseconds.
> Therefore a connection could be idle for as long as 1.5 * IdleTimeout
> before being removed.
>
> BlockingTimeout/LoginTimout only throws an exception if all the
> connections
> in a pool are checked out and none are returned within the specified
> time:
> it does not take any account of time to actually set up the connection
> with
> firebird.
>
> When you are done with a connection, call close() on it, that returns it
> to
> the pool.
>
> If you leave pooling=false (default) you get no pooling, as before:
> closing
> a connection really closes the physical connection to firebird.
>
> Thanks
> david jencks
>