cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Giacomo Pati <giac...@apache.org>
Subject Re: [C2] DataSourcese Proposal (first draft)
Date Thu, 11 Jan 2001 21:03:22 GMT
Berin Loritsch wrote:
> 
> Giacomo Pati wrote:
> 
> > Berin Loritsch wrote:
> >
> >
> >> Giacomo Pati wrote:
> >
> >>
> >
> >>
> >>> Berin Loritsch wrote:
> >
> >>>
> >
> >>>
> >>>> I added the code for a robust JdbcDataSources Proposal.
> >
> >>>> Please cross-check and pound on it.  The second phase
> >
> >>>> (J2eeDataSource) will be much simpler because we are
> >
> >>>> relying on the J2EE Container to implement the pooling.
> >
> >>>
> >>>
> >>> I'll test it out tomorrow. You'll get feedback (probabbly as CVS Update
> >
> >>> mails :)
> >
> >>
> >> Kool Beans!  Please note, you can still use the archaic
> >
> >> methodology of specifying the connection parameters and
> >
> >> creating a new Connection object for EACH request.  Or
> >
> >> you can use the high powered pooled DataSources and keep
> >
> >> the configurations for the entire site in one location!
> >
> >
> >
> > Yes, I've noticed this and used it already for a little eShop. Using a
> >
> > pool of connections is the way to go for my. It dosn't make any sense
> >
> > and in fact it can be very costly to open a connection for EVERY
> >
> > request. Oracle for exaple is one of those DBs that opening a connection
> >
> > is a performance nightmare.
> >
> >
> >
> >
> >> As a side note, I found that the SQLTransformer sample
> >
> >> in CVS used and closed no fewer than 11 connections--
> >
> >> no wonder it's performance lagged behind esql logicsheet!
> >
> >> Can the maintainer of the SQLTransformer work on getting
> >
> >> that down to one per connection actually needed?
> >
> >
> >
> > Well that piece is way old. It was a test example from Donald Ball and I
> >
> > have fixed it to make it work but this was in spring last year :/
> >
> >
> >
> >
> >>>> If you have any questions as to its use, feel free to
> >
> >>>> ask--although it should be pretty clear.
> >
> >>>
> >>>
> >>> I've just seen you don't use defaults on the
> >
> >>> conf.getChild("user").getValue() which will throw a
> >
> >>> ConfigurationException. But your further code allows that for
> >
> >>> user/pasword encoded in the dburl, right?
> >
> >>
> >> Actually, as a result of synching up with Avalon
> >
> >> code, and Avalon started throwing ConfigurationExceptions
> >
> >> when an element did not exist, I asked for a feature
> >
> >> enhancement.  Basically, when you ask for a child
> >
> >> configuration object that is not defined in the file,
> >
> >> the parent creates an empty child element--with a null
> >
> >> value.
> >
> >>
> >
> >> Also, the AbstractConfiguration has been updated to
> >
> >> eliminate NullPointerExceptions escaping from the
> >
> >> get[Value|Attribute]As[Boolean|Int|Long|Float|Double]();
> >
> >> calls.
> >
> >
> >
> > Ok. But as for the code in the CVS if you use the dburl to specify
> >
> > user/password or if you have a user without a password and you only
> >
> > specify empty user and/or password elements you'll get an exception,
> >
> > right?
> 
> Huh?  That's a mouthful.  Lets see if I can answer it a piece at a time:
> 
> dburl--MUST be provided (how else can you connect?)--Exception is thrown on violation

Agreed

> user--OPTIONAL (not everyone in test environments deals with logins)--No Exception thrown
unless JDBC driver throws it

Optional mean what? Empty element or no element at all?

> password--REQUIRED when user is supplied--Exception is thrown on violation

When you talk about test environment there are cases where you don't
have a password for a user. Or the DBMS dosn't allow logins without a
name but without a password. I work with postgresql DBMS which allows
you to login without a password if your connection comes from localhost
but requires one if you login from remote.

Giacomo

> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org

Mime
View raw message