Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Message-ID: <3A56BA3D.D2853DA7@infoplanning.com>
Date: Sat, 06 Jan 2001 01:25:01 -0500
From: Berin Loritsch <bloritsch@infoplanning.com>
MIME-Version: 1.0
To: cocoon-dev@xml.apache.org
Subject: Re: [C2] DataSources Proposal
References: <3A5639CA.6010707@apache.org> <3A564F33.4578884@apache.org>
 <20010105234530.J682@hydrogen.internal.luminas.co.uk>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Paul Russell wrote:
> 
> * Giacomo Pati (giacomo@apache.org) wrote :
> > Berin Loritsch wrote:
> > > In both instances, the DataSource is a Component, so every XSP page or any other
> > > Composer will be able to have access to it.  (Imagine setting Actions to directly
> > > handle the database without having to worry about complex configurations).
> > +1024^1024 :))
> 
> I can feel an ArithmeticException coming on... ;)
> 
> > > Toward that end, I need to know if this is something that you guys would be interested
> > > in having in the Cocoon source.
> > +1 again
> 
> Definately and absolutely. Sorry I didn't reply earlier - tied up at work
> at the moment.
> 
> > > If that is the case, I need to know what package name
> > > to use.  I was thinking the following:
> > > org.apache.cocoon.components.datasource/
> > > DataSourceComponent
> > > JdbcDataSource
> > > J2eeDataSource
> 
> Fine by me. +1.
> 
> > Having this as a Component in the cocoon.xconf file is exactly what I'd
> > like. I was thinking about how to implement a JDBC connection pool and
> > looked into C1. But the Turbine pool isn't what I'd like to have in C2
> > because it's not a Avalon Component and I think it doesn't fit into the
> > C2 architecture.
> 
> Agreed. I started to do some work on it a while back when I (briefly)
> started porting the esql tablib to C2. The Turbine stuff is good, but I
> think we need something a little more general these days. Can't help
> feeling there should be a central repository of interesting Avalon
> components (note: not blocks, although I think that will come too).
> 
> Berin: I'm (relatively) free this weekend (read: only one project to
> work on!) -- is there anything I can do to help?

Well, I put the initial stuff in already. I do think that the DataSourceComponent
needs to be/control its own pool to handle the Connection.close() issue.
Basically, once a connection is closed, it must either be reopened, or rebuilt.

The way the javax.sql Connection Pooling works is that when the Connection is
closed, the Connection really remains open but is returned to the pool.  When
the pool is destroyed, the individual Connections are finally closed.

To that end, I need a Connection Proxy object that takes care of returning the
Connection to the pool when it is "closed" by the user.  A separate method
called destroy() will actually close the connection.

Anyhow, what I have assumes the Connection stays open--which is not real life.