Well, now I'm agreeing with you more ;-)

On 2001.11.11 15:17:40 -0500 Massimo Ferrari wrote:
> 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),

I'm reluctantly coming to the conclusion that to make the driver
jca-compliant we have to fix this so autocommit = true if no other
transaction control has happened.

> 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).

This is probably a good idea too. I think perhaps the best solution is
another DataSource class that you can set the properties on (the properties
now in ManagedConnectionFactory) and that will create and set up the
ManagedConnectionFactory, and make the ManagedConnectionFactory use it for
its DataSource.

> 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

What I don't want to see happen is the jca architecture compromised to
support the Driver class. Adding conveniences such as the javabean
DataSource that do not obstruct the jca framework is not a problem for me.
(Not sure when I might do it, but even I might write it if I get a little
free time ;-)

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