Well, I really agree with you, but *sorry* -I hope I don't bother you-, I'm
still not completely convinced.
JCA is not an extension of JDBC, but a pluggability enhancement for J2EE
platforms big enough to have their own transaction/connection/security
management facility.
But what about the tons of code/libraries written until now which still rely
on JDBC2.0 (w/out std ext)?
The main problem is that this driver is designed for the future (well, not
bad :) ) but forgets the past...
I could easily substitute my
javax.sql.DataSource ds = new mydb.MyDataSource();
with
javax.sql.DataSource ds =
(javax.sql.DataSource)managedConnectionFactory.createConnectionFactory()
to get a connection (although the last one would be an unmanaged connection
with autocommit=false),
but I could not easily (or at least without doubts about its correct
functionality) configure e.g. castor (which can be configured with a Driver
or a DataSource only, and which expects the DataSource to be a JavaBean with
a default constructor with no args) to load the firebirdsql Driver (and not
the FBDataSource since it has no no-args constructors).
I hope you don't misunderstand, I find your job really great, like the fact
that this driver is built following the JCA specs from scratch, but I even
find that to make this driver really useful, JCA should be as transparent as
possible (i.e. hidden) for the users that expect to use this library as a
JDBC driver only.
Massimo

----- Original Message -----
From: "David Jencks" <davidjencks@...>
To: <IB-Java@yahoogroups.com>
Sent: Sunday, November 11, 2001 6:34 PM
Subject: Re: [IB-Java] Unmanaged scenario


> 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/
> >
> >
> >
> >
> >
>
>
> 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/
>
>
>