Aaron, 

I think we need to be more ambitious than that.

The pools in my mind are taking space.  It is a critical feature that
"JOnAS" never got quite right, and I am very happy to see addressed
here.  They are not "Just" jdbc connections to be sure but an
implementation of J2EE specs in their own right.   

The second thing is that I believe there is some independency between
the pool mechanisms and jBoss, so that we do want to have a separate
packaging.

I therefore propose that we start a small subproject for the pool
management. It should live on jboss-dev for now but at least have a name
so that people are willing to go on "X" as opposed to vague terms.

You are rather new in your public appearances on the list Aaron but at
least seem to have a good grasp of what you are doing and I believe it
can work.

I will initiate a board vote on that, in the meantime, any good names
for the pool managers/ JDBC thingies????

regards
marc
 

Aaron Mulder wrote:
> 
>         Okay, where should I package the code?  Under org.jboss.jdbc or
> org.jboss.ejb.plugins.jdbc?  I'd suggest we create separate sub-packages
> for:
> 
>  - JDBC Pools
>  - 1.1 XA wrapper
>  - Configuration interface (this may go in the main jdbc package)
> 
>         Only that last would be a "public" interface - the rest would be
> accessible via JNDI or JDBC URLs only, or used under the covers.
> 
> Aaron
> 
> On Mon, 22 May 2000, Rickard [iso-8859-1] �berg wrote:
> > Hi!
> >
> > Aaron Mulder wrote:
> > > On Mon, 22 May 2000, Rickard [iso-8859-1] �berg wrote:
> > > > Hold on!!! You have used a *connection* (a pipe, something to send stuff
> > > > through, but *not* a data storage) to execute queries. All that data has
> > > > been sent to the database. The data is *not* tied to the connection as
> > > > such, it is tied to the *tx*. The connection is just a pipe we use to
> > > > shuffle our stuff through.
> > >
> > >         I wasn't aware you could distinguish between a connection and a
> > > transaction in JDBC.  But perhaps this is what you meant when you talked
> > > about 2.0 drivers.
> >
> > Exactly. In JDBC 1.0 con's and tx's are tied very strongly to each
> > other. Now, with the XAResource thing this coupling is much more loose.
> >
> > > So you're saying that with a "2.0" driver, the DBMS
> > > vendor implements XAResources and XAConnections within their driver, so
> > > we don't deal directly with the connections or transactions - they handle
> > > it all for us.  Magical!
> >
> > Right on :-)
> >
> > >         I went back and looked at the Oracle drivers, and discovered that
> > > that latest drivers do indeed support this - they provide an XADataSource.
> > > That sures saves a bundle of work!  NOW we're on the same page!
> >
> > Yep, that saves a LOT of work :-)
> >
> > >         However, this simply raises a new and different set of questions.
> > > Sigh.
> > >
> > > 1) How many drivers implement this?  I suspect not too many, but I'd love
> > > ot be surprised.
> >
> > Exactly, which is why I proposed a JDBC1.0 driver wrapper that makes any
> > non-2.0 driver appear as though it was 2.0. Of course, it will always
> > fail on "prepare" and "commit" (since JDBC 1.0 is 1-phase only!), so the
> > tx-manager will have to make sure to use the 1-phase optimization if
> > possible.
> >
> > > 2) Unfortunately, the DataSource interface does not include any methods
> > > for configuring the DataSource.  That is, there's no standard way to
> > > specify the server, port, instance/database, URL, etc.  The spec suggests
> > > that the implementation be beany (get/set for all properties), but only
> > > "suggests" the properties.  So how do we allow configuration?  I suppose
> > > we can take a property list and try to invoke an appropriate setXXX method
> > > for each proparty via reflection, and error out if we can't find an
> > > appropriate method...
> >
> > Exactly.
> >
> > > 3) What do we do with drivers that don't implement this?  I think we may
> > > have the same intention here, which is to create a wrapper for 1.0 drivers
> > > where we implement all the XA stuff and prevent bad things from happening.
> >
> > See above. Yes. Non-trivial, but the only way to go IMHO.
> >
> > /Rickard
> >
> > --
> > Rickard �berg
> >
> > @home: +46 13 177937
> > Email: [EMAIL PROTECTED]
> > http://www.telkel.com
> > http://www.jboss.org
> > http://www.dreambean.com
> >

-- 

----------------------------------------------------------------
Visit Telkel at JavaOne(SM), Sun's 2000 Worldwide Java Developer
Conference(SM)
June 5-9, 2000 - Moscone Center - San Francisco

Reply via email to