cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <blorit...@apache.org>
Subject Re: [C2] DataSourcese Proposal (first draft)
Date Wed, 10 Jan 2001 21:30:53 GMT
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
user--OPTIONAL (not everyone in test environments deals with logins)--No Exception thrown
unless JDBC driver throws it
password--REQUIRED when user is supplied--Exception is thrown on violation


Mime
View raw message