The Driver interface was pronounced obsolete in jdbc 2: jdbc 2.0 standard
extension spec, version 1, Dec 7. 1998, sec 5.7, p 15:

"we encourage developers to regard the DriverManager as a legacy feature of
the JDBC API. Applications should use the DataSource API whenever
possible."

Instead of trying to make the support of this legacy feature the primary
goal and central architectural feature of the client-java driver, how about
modernizing other applications to use DataSources and JCA? The FBDriver
works fine, as far as I can tell, if you only need one connection. If you
need more, you should be using a DataSource (since 1998). If you need
pooling, you should be using a DataSource with a ConnectionManager that
supports pooling. (We could use such a ConnectionManager: I hope to write
one, but it may be a while...)

On 2001.11.11 11:44:44 -0500 Massimo Ferrari wrote:
> Ok, but I still don't see why DataSource and Driver should not share a
> common implementation.
> The DataSource should be a JavaBean, the default constructor could
> initialize by itself the FBStandAloneConnectionManager,
This might be desirable, but would cause architectural difficulties. Right
now all FBDataSources are constructed in a call to
FBManagedConnectionFactory.getConnectionFactory(). To support creating the
whole framework from a DataSource constructor, we would have to include an
analogous method on FBManagedConnectionFactory that took the already
created unconfigured FBDataSource as a parameter: this method is not
included in the jca spec.

or even better
> the
> Driver self could keep its own instance of the
> FBStandAloneConnectionManager
> and use it to get connections.

Well, the Driver would have to keep a map of database url + config info to
FBManagedConnectionFactory instances, and see if it had an appropriate
FBManagedConnectionFactory instance each time you asked for a connection.
I think it's easier to use the interfaces designed for this, and let Driver
handle single connections with reasonable efficiency, and let it die a
deserved death for more complicated scenarios.
> Under a certain point of view (it doesn't support JCA) that's what e.g.
> the
> mm mysql driver does (the DataSource just delegates connection creations
> to
> the Driver).
> This would make coherent the Driver's behaviour in an unmanaged scenario:
> new connections only through the DriverManager which uses the installed
> ConnectionManager to allocate them.

IMHO this strategy was obsolete in 1998.

david jencks
>
> Massimo
>
>
> ----- Original Message -----
> From: "David Jencks" <davidjencks@...>
> To: <IB-Java@yahoogroups.com>
> Sent: Sunday, November 11, 2001 3:24 PM
> Subject: Re: [IB-Java] Unmanaged scenario
>
>
> > The Driver.conect method does use the StandAloneConnectionManager to
> get
> > its connection. However, it creates a FBManagedConnectionFactory and
> > FBStandAloneConnectionManager for each connection you ask for.
> Therefore,
> > using a FBDataSource obtained from a explicitly created
> > FBManagedConnectionFactory is considerably more efficient if you need
> more
> > than one connection in your app. It also provides the opportunity to
> use
> a
> > different ConnectionManager that supports e.g. pooling.
> >
> > david jencks
> >
> > On 2001.11.11 03:10:19 -0500 Massimo Ferrari wrote:
> > > > Would the autocommit support outlined above be pretty much what you
> > > want?
> > >
> > > That would be surely great.
> > > Further, what you said is right, for the unmanaged scenario the RA's
> > > default
> > > ConnectionManager must be used: so why not use it in Driver.connect
> to
> > > create the "un"managed connection? I think there should be no
> difference
> > > in
> > > getting a connection through the Driver or through the DataSource,
> both
> > > should rely on the current ConnectionManager.
> > >
> > > Massimo
> > >
> > >
> > >
> > >
> > > To unsubscribe from this group, send an email to:
> > > IB-Java-unsubscribe@egroups.com
> > >
> > >
> > >
> > > Your use of Yahoo! Groups is subject to
> http://docs.yahoo.com/info/terms/
> > >
> > >
> > >
> > >
> > >
> >
> > To unsubscribe from this group, send an email to:
> > IB-Java-unsubscribe@egroups.com
> >
> >
> >
> > Your use of Yahoo! Groups is subject to
> http://docs.yahoo.com/info/terms/
> >
> >
> >
>
>
>
> To unsubscribe from this group, send an email to:
> IB-Java-unsubscribe@egroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>
>
>