You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Vincent Massol <vm...@octo.com> on 2001/12/22 20:09:18 UTC
Synergies between Avalon and Commons projects ?
I'd like to have your opinion on the possible synergies between Avalon
and the Commons projects on reuse and sharing.
Here are some of my thoughts :-)
* Avalon is a service framework (ok, component and service framework)
and is suited for lots of projects but some projects may not need/want
to use the small Avalon wrapper which is layered on top of the java
classes and may want to use directly the implementation (like using a
jdbc pool but not as an Avalon component which needs to be managed by a
component manager)
* On the other hand, Commons is geared towards providing context neutral
libraries which could be used in any context.
* Thus, one solution could be to put in Commons the bare implementation
(like the jdbc pool implementation) and put in Avalon a component
wrapper on top of it (and reference the commons jars).
* Thus, the bare implementation can also be used independently of
Avalon.
* For example, we could easily provide an Avalon component which would
wrap around the commons digester, etc.
What do you think ?
If there is an agreement, this should probably be done slowly, one
library at a time. I guess, I'm not sure about the knowledge both
projects have of each other. I have been using both and I see a lot of
possible code reuse/benefits.
Thanks
-Vincent
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Breaking Excalibur into smaller swords (was Re: Synergies between Avalon and Commons projects ?)
Posted by Peter Donald <pe...@apache.org>.
On Tue, 25 Dec 2001 00:31, Berin Loritsch wrote:
> Peter Donald wrote:
> > On Sun, 23 Dec 2001 12:19, Peter Donald wrote:
> >>A week or two ago I made a proposal to separate distribution of them so I
> >>didn't have to grab all of excalibur to use them.
> >
> > actually it seems like I didn't or at least I couldn't find it in my
> > archives... hmm may resend it
>
> We are on the same page. I thought I sent something along those lines
> myself in the same time frame....
>
> The issue is what is the component mix?
My immediate needs are
excalibur-naming.jar
excalibur-cli.jar
excalibur-extensions.jar
excalibur-io.jar
Theres a whole bunch of stuff that I would be willing to move into excalibur
from different projects if we go this path. Examples being
* jmx stuff from phoenix
* converter stuff from myrmidon (ant proposal)
* encoding/decoding for ~ASN/BER/CDR/etc stuff (from my own stuff)
--
Cheers,
Pete
---------------------------------------------------------
Clarke's Third Law: "Any technology distinguishable from
magic is insufficiently advanced".
---------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Breaking Excalibur into smaller swords (was Re: Synergies between Avalon and Commons projects ?)
Posted by Berin Loritsch <bl...@apache.org>.
Peter Donald wrote:
> On Sun, 23 Dec 2001 12:19, Peter Donald wrote:
>
>>A week or two ago I made a proposal to separate distribution of them so I
>>didn't have to grab all of excalibur to use them.
>>
>
> actually it seems like I didn't or at least I couldn't find it in my
> archives... hmm may resend it
We are on the same page. I thought I sent something along those lines myself
in the same time frame....
The issue is what is the component mix?
There should still remain an Excalibur archive that is the whole thing.
I have a feeling when all is said and done we will have the following
distributions:
excalibur-component.jar (container, component, logmanager)
excalibur-datasource.jar
excalibur-xml.jar (xpath, parser, xslt object, etc.)
excalibur-url.jar (source, resource, etc.)
excalibur-async.jar (monitor, event, etc.)
excalibur.jar (all of it)
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Synergies between Avalon and Commons projects ?
Posted by Peter Donald <pe...@apache.org>.
On Sun, 23 Dec 2001 12:19, Peter Donald wrote:
> A week or two ago I made a proposal to separate distribution of them so I
> didn't have to grab all of excalibur to use them.
actually it seems like I didn't or at least I couldn't find it in my
archives... hmm may resend it
--
Cheers,
Pete
"The perfect way is only difficult for those who pick and choose. Do not
like, do not dislike; all will then be clear. Make a hairbreadth
difference and heaven and earth are set apart; if you want the truth to
stand clear before you, never be for or against." - Bruce Lee
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Synergies between Avalon and Commons projects ?
Posted by Peter Donald <pe...@apache.org>.
On Sun, 23 Dec 2001 06:09, Vincent Massol wrote:
> I'd like to have your opinion on the possible synergies between Avalon
> and the Commons projects on reuse and sharing.
>
> Here are some of my thoughts :-)
>
> * Avalon is a service framework
a small part of Avalon is a service framework
> * On the other hand, Commons is geared towards providing context neutral
> libraries which could be used in any context.
not really. Rather than explicit code based typing it relies on code
conventions. It is easier to integrate into existing systems which was why
when commons was initially forming I believe it was me who started vote for
that way and disallowing imports of any framework libs.
> * Thus, one solution could be to put in Commons the bare implementation
> (like the jdbc pool implementation) and put in Avalon a component
> wrapper on top of it (and reference the commons jars).
>
> * Thus, the bare implementation can also be used independently of
> Avalon.
The majority of the components in excalibur are independent of Framework. A
week or two ago I made a proposal to separate distribution of them so I
didn't have to grab all of excalibur to use them.
> What do you think ?
Its nothing that interests me to do - if you want to do it then go for it. As
long as the quality of Avalons components is not degraded (will not accept
making immutable objects mutable just so they can be configuerd as beans)
then theres nothing wrong with it. Actually in the past I have had requests
to reimplement functionality from commons (Turbines property wrapper which I
believe was moved to commons) so in that case it would be good.
--
Cheers,
Pete
------------------------------
Kitsch never goes out of style
------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Synergies between Avalon and Commons projects ?
Posted by Paul Hammant <Pa...@yahoo.com>.
Vincent,
I have a view that if something is in Phoenix or Framework but is
equally usable to client-side graphical applications or Applets, then
perhaps it should not be in those two Avalon sub-projects. Excalibur
needs to be broken into multiple jars, each available directly from the
Jakarta website, but you'll have to forgive us for concentrating on
keeping things inside the Avalon project. It is driven from a simple
need, we're trying to encourage as many as possible to start or migrate
their server projects to some part of the Avalon framework.
As for Logkit, perhaps we should spend more time making interface/impl
separations for the jars too. Or maybe separate jars in addition to an
all in one jar..
With respect to migrations from Avalon to Commons, does that sound
nearer to your vision?
There is also an issue of useful commons code being mountable in Avalon
apps. Take for example the HttpClientConnection. It has constructors
of ....
public HttpConnection(String host, int port);
public HttpConnection(String host, int port, boolean secure);
public HttpConnection(String proxyHost, int proxyPort, String host,
int port);
public HttpConnection(String proxyHost, int proxyPort, String host,
int port, boolean secure);
... this is quite usable, but with Cornerstone we have class that
already grant outgoing socket connections. Whilst I am not suggesting
you use then, perhaps more constructors could be made that might allow a
developer choosing Avalon as platform byt wanting to use HttpConnection
from commons to do so and hand a socket, streams or some abstract thing
to HttpConnection. The Log abstraction in this tool is good, but you
might want to have a LogKit adapter as well as a Log4J adapter :-)
Regards,
- Paul H
>I'd like to have your opinion on the possible synergies between Avalon
>and the Commons projects on reuse and sharing.
>
>Here are some of my thoughts :-)
>
>* Avalon is a service framework (ok, component and service framework)
>and is suited for lots of projects but some projects may not need/want
>to use the small Avalon wrapper which is layered on top of the java
>classes and may want to use directly the implementation (like using a
>jdbc pool but not as an Avalon component which needs to be managed by a
>component manager)
>
>* On the other hand, Commons is geared towards providing context neutral
>libraries which could be used in any context.
>
>* Thus, one solution could be to put in Commons the bare implementation
>(like the jdbc pool implementation) and put in Avalon a component
>wrapper on top of it (and reference the commons jars).
>
>* Thus, the bare implementation can also be used independently of
>Avalon.
>
>* For example, we could easily provide an Avalon component which would
>wrap around the commons digester, etc.
>
>What do you think ?
>
>If there is an agreement, this should probably be done slowly, one
>library at a time. I guess, I'm not sure about the knowledge both
>projects have of each other. I have been using both and I see a lot of
>possible code reuse/benefits.
>
>Thanks
>-Vincent
>
>
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Database Connection Pool
Posted by Paul Hammant <Pa...@yahoo.com>.
Randy Speh wrote:
>Thanks for the info. Would you mind telling me the
>differences between Avalon and Fulcrum/Commons.
>
>I just wasn't aware of Avalon for some reason. I've
>been submerged in Turbine, Torque, Fulcrum and Commons
>code.
>
It is big. See http://jakarta.apache.org/avalon/
Commons has some overlap with Excalibur only.
Regards,
- Paul H
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Database Connection Pool
Posted by Paul Hammant <Pa...@yahoo.com>.
Randy,
>Could you please tell me where the document is on how
>to configure and start and access Avalon's connection
>pool.
>
Wrong list and "using my brain".
Get Avalon (four projects) from CVS. Use "Find in Files" or equiv to
find source containing "ConnectionPool" or just "Pool" for more fun.
Regards,
- Paul H
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Database Connection Pool
Posted by Berin Loritsch <bl...@apache.org>.
Randy Speh wrote:
> Could you please tell me where the document is on how
> to configure and start and access Avalon's connection
> pool.
The javadocs for the JDBC DataSource are here:
http://jakarta.apache.org/avalon/excalibur/api/org/apache/avalon/excalibur/datasource/JdbcDataSource.html
There is more information in the Avalon Developers Docs in Chapter 3:
http://jakarta.apache.org/avalon/developing/implementing.html
But it is interspersed in instructions for how to use other parts of
Avalon.
It is an Avalon Component, so it is not easily separated.
If you forgo the nice configuration interface, you can set it up programatically
like this:
Class.forName("oracle.jdbc.driver.OracleDriver");
JdbcConnectionFactory factory = public JdbcConnectionFactory("jdbc:oracle:thin:@localhost:1521:ORCL",
"scott", "tiger", false /* autocommit? */,
"SELECT 1 FROM DUAL",
"org.apache.avalon.excalibur.datasource.JdbcConnection");
DefaultPoolController controller = new DefaultPoolController( 2 /* grow amount */ );
JdbcConnectionPool datasourcePool = new JdbcConnectionPool( factory, controller, 2 /* min */, 10 /* max */, false /* autocommit? */
datasourcePool.setTimeout( 500 ); // set time in millis pool will block waiting for a connection to be returned to an empty pool
datasourcePool.initialize();
// the datasourcePool is active now
(Connection) datasourcePool.get();
// when the pool is ready to be shut down
datasourcePool.dispose();
A little explanation follows:
The pool assumes that the driver is actually installed in the classpath, and
the class has been loaded.
The JdbcConnectionFactory is used to create the Connection objects. The Connection
objects must extend AbstractJdbcConnection. In Avalon there are two JdbcConnection
implementations: JdbcConnection for JDBC 2.0 compliant drivers, and Jdbc3Connection
for JDBC 3.0 compliant drivers (aka JDK 1.4).
The parameter names for the JdbcConnectionFactory are as follows:
public JdbcConnectionFactory(java.lang.String url,
java.lang.String username,
java.lang.String password,
boolean autoCommit,
java.lang.String keepAlive,
java.lang.String connectionClass)
The parameter names for the datasourcePool are as follows:
public JdbcConnectionPool(JdbcConnectionFactory factory,
DefaultPoolController controller,
int min,
int max,
boolean autoCommit)
The initialization of the pool is asynchronous, and starts when you call initialize();
If you ask for a connection before the pool is fully initialized, it will block until
the pool is ready. This allows the pool to open new connections (which can take upwards
of a second or more per connection) in the background while your application finishes
initializing. Most of the time, the pool is done initializing before you request the
first datasource.
There might be a detail or two I am missing, but that is because I use the JdbcDataSource
Component, which takes advantage of Avalon Framework's lifecycle methods. The full
component takes care of all the details as long as you pass it a valid configuration
object.
>
> Thank you,
> Randy Speh
>
>
>
> --- Berin Loritsch <bl...@apache.org> wrote:
>
>>Randy Speh wrote:
>>
>>
>>>Thanks for the info. Would you mind telling me
>>>
>>the
>>
>>>differences between Avalon and Fulcrum/Commons.
>>>
>>>I just wasn't aware of Avalon for some reason.
>>>
>>I've
>>
>>>been submerged in Turbine, Torque, Fulcrum and
>>>
>>Commons
>>
>>>code.
>>>
>>
>>Honestly, I can only tell you what Avalon does (I
>>wrote
>>the code for the DB pooling). I don't know what
>>Fulcrum
>>is much less what it does. As for Commons, I have
>>only
>>had a cursory look at it, so I am not the one to
>>answer this.
>>
>>
>>
>>>Thanks,
>>>Randy
>>>--- Berin Loritsch <bl...@apache.org> wrote:
>>>
>>>
>>>>Randy Speh wrote:
>>>>
>>>>
>>>>
>>>>>I would be very interested to see what your
>>>>>
>>>>>
>>>>connection
>>>>
>>>>
>>>>>pooling code looks like. I been trying to choose
>>>>>
>>>>>
>>>>the
>>>>
>>>>
>>>>>most appropriate connection pooling technique and
>>>>>
>>>>>
>>>>have
>>>>
>>>>
>>>>>been considering adapting one myself. Although,
>>>>>
>>>>>
>>>>I'd
>>>>
>>>>
>>>>>really rather use something from the open source
>>>>>community.
>>>>>
>>>>>
>>>>>
>>>>Currently there is dbcp in Commons, Turbine
>>>>connection pooling,
>>>>and Avalon connection pooling.
>>>>
>>>>Both DBCP and Avalon provide similar semantics
>>>>inspired by
>>>>the official JDBC DataSource specifications--when
>>>>you "close"
>>>>the connection, it returns the Connection to the
>>>>pool. Turbine
>>>>(if I recall) makes you explicitly return it to
>>>>
>>the
>>
>>>>pool yourself.
>>>>
>>>>I won't get involved with which is the best
>>>>
>>pattern.
>>
>>>>Beyond that basic difference, there is alot of
>>>>difference in the
>>>>manner that the connection pools are configured.
>>>>Since I don't
>>>>have any real information on DBCP and Turbine
>>>>pooling, I won't
>>>>talk about them. Here is what Avalon's
>>>>Configuration looks like:
>>>>
>>>><connection>
>>>> <pool-controller min="2" max="10" grow="2">
>>>> <keep-alive>SELECT 1 FROM DUAL</keep-alive>
>>>> </pool-controller>
>>>>
>>>>
>>>>
>><driver>oracle.jdbc.driver.OracleDriver</driver>
>>
>>>>
>>>>
>>><dburl>jdbc:oracle:thin:@localhost:1521:ORCL</dburl>
>>>
>>>> <user>scott</user>
>>>> <password>tiger</password>
>>>></connection>
>>>>
>>>>The Pool Controller specifies how many connections
>>>>the pool starts
>>>>with ("min"), the absolute maximum number of
>>>>connections ("max"),
>>>>and how many new connections it creates at a time
>>>>when it needs
>>>>more ("grow"). It is important to note that the
>>>>maximum is absolute.
>>>>The pool will not go beyond that maximum number.
>>>>The reason being
>>>>that some drivers have license restrictions and it
>>>>helps the pool
>>>>to not violate the license. The last part
>>>>("keep-alive") is the
>>>>query used by the pool to determine if the
>>>>connection has been closed
>>>>by the server. We found out that not all
>>>>
>>databases
>>
>>>>are created
>>>>equal, and while "SELECT 1" works for many
>>>>databases, Oracle requires
>>>>that "1" be selected from the dummy table "DUAL",
>>>>and others like
>>>>Informix require you to select from an
>>>>
>>application's
>>
>>>>table.
>>>>
>>>>You can determine for yourself if this is
>>>>desirable--and possibly
>>>>DBCP might steal ideas to narrow the differences.
>>>>Who knows....
>>>>
>>>>
>>>>--
>>>>
>>>>"They that give up essential liberty to obtain a
>>>>little temporary safety
>>>> deserve neither liberty nor safety."
>>>> - Benjamin Franklin
>>>>
>>>>
>>>>--
>>>>To unsubscribe, e-mail:
>>>>
>>><ma...@jakarta.apache.org>
>>>
>>>>For additional commands, e-mail:
>>>><ma...@jakarta.apache.org>
>>>>
>>>
>>>__________________________________________________
>>>Do You Yahoo!?
>>>Send your FREE holiday greetings online!
>>>http://greetings.yahoo.com
>>>
>>>--
>>>To unsubscribe, e-mail:
>>>
>><ma...@jakarta.apache.org>
>>
>>>For additional commands, e-mail:
>>>
>><ma...@jakarta.apache.org>
>>
>>>.
>>>
>>>
>>>
>>
>>
>>--
>>
>>"They that give up essential liberty to obtain a
>>little temporary safety
>> deserve neither liberty nor safety."
>> - Benjamin Franklin
>>
>>
>>--
>>To unsubscribe, e-mail:
>><ma...@jakarta.apache.org>
>>For additional commands, e-mail:
>><ma...@jakarta.apache.org>
>>
>
>
> __________________________________________________
> Do You Yahoo!?
> Send your FREE holiday greetings online!
> http://greetings.yahoo.com
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
> .
>
>
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Database Connection Pool
Posted by Randy Speh <rw...@yahoo.com>.
Could you please tell me where the document is on how
to configure and start and access Avalon's connection
pool.
Thank you,
Randy Speh
--- Berin Loritsch <bl...@apache.org> wrote:
> Randy Speh wrote:
>
> > Thanks for the info. Would you mind telling me
> the
> > differences between Avalon and Fulcrum/Commons.
> >
> > I just wasn't aware of Avalon for some reason.
> I've
> > been submerged in Turbine, Torque, Fulcrum and
> Commons
> > code.
>
>
> Honestly, I can only tell you what Avalon does (I
> wrote
> the code for the DB pooling). I don't know what
> Fulcrum
> is much less what it does. As for Commons, I have
> only
> had a cursory look at it, so I am not the one to
> answer this.
>
>
> >
> > Thanks,
> > Randy
> > --- Berin Loritsch <bl...@apache.org> wrote:
> >
> >>Randy Speh wrote:
> >>
> >>
> >>>I would be very interested to see what your
> >>>
> >>connection
> >>
> >>>pooling code looks like. I been trying to choose
> >>>
> >>the
> >>
> >>>most appropriate connection pooling technique and
> >>>
> >>have
> >>
> >>>been considering adapting one myself. Although,
> >>>
> >>I'd
> >>
> >>>really rather use something from the open source
> >>>community.
> >>>
> >>>
> >>
> >>Currently there is dbcp in Commons, Turbine
> >>connection pooling,
> >>and Avalon connection pooling.
> >>
> >>Both DBCP and Avalon provide similar semantics
> >>inspired by
> >>the official JDBC DataSource specifications--when
> >>you "close"
> >>the connection, it returns the Connection to the
> >>pool. Turbine
> >>(if I recall) makes you explicitly return it to
> the
> >>pool yourself.
> >>
> >>I won't get involved with which is the best
> pattern.
> >>
> >>Beyond that basic difference, there is alot of
> >>difference in the
> >>manner that the connection pools are configured.
> >>Since I don't
> >>have any real information on DBCP and Turbine
> >>pooling, I won't
> >>talk about them. Here is what Avalon's
> >>Configuration looks like:
> >>
> >><connection>
> >> <pool-controller min="2" max="10" grow="2">
> >> <keep-alive>SELECT 1 FROM DUAL</keep-alive>
> >> </pool-controller>
> >>
> >>
> <driver>oracle.jdbc.driver.OracleDriver</driver>
> >>
>
>><dburl>jdbc:oracle:thin:@localhost:1521:ORCL</dburl>
> >> <user>scott</user>
> >> <password>tiger</password>
> >></connection>
> >>
> >>The Pool Controller specifies how many connections
> >>the pool starts
> >>with ("min"), the absolute maximum number of
> >>connections ("max"),
> >>and how many new connections it creates at a time
> >>when it needs
> >>more ("grow"). It is important to note that the
> >>maximum is absolute.
> >>The pool will not go beyond that maximum number.
> >>The reason being
> >>that some drivers have license restrictions and it
> >>helps the pool
> >>to not violate the license. The last part
> >>("keep-alive") is the
> >>query used by the pool to determine if the
> >>connection has been closed
> >>by the server. We found out that not all
> databases
> >>are created
> >>equal, and while "SELECT 1" works for many
> >>databases, Oracle requires
> >>that "1" be selected from the dummy table "DUAL",
> >>and others like
> >>Informix require you to select from an
> application's
> >>table.
> >>
> >>You can determine for yourself if this is
> >>desirable--and possibly
> >>DBCP might steal ideas to narrow the differences.
> >>Who knows....
> >>
> >>
> >>--
> >>
> >>"They that give up essential liberty to obtain a
> >>little temporary safety
> >> deserve neither liberty nor safety."
> >> - Benjamin Franklin
> >>
> >>
> >>--
> >>To unsubscribe, e-mail:
>
>><ma...@jakarta.apache.org>
> >>For additional commands, e-mail:
> >><ma...@jakarta.apache.org>
> >>
> >
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Send your FREE holiday greetings online!
> > http://greetings.yahoo.com
> >
> > --
> > To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> <ma...@jakarta.apache.org>
> >
> > .
> >
> >
>
>
>
> --
>
> "They that give up essential liberty to obtain a
> little temporary safety
> deserve neither liberty nor safety."
> - Benjamin Franklin
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
__________________________________________________
Do You Yahoo!?
Send your FREE holiday greetings online!
http://greetings.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Database Connection Pool
Posted by Berin Loritsch <bl...@apache.org>.
Randy Speh wrote:
> Thanks for the info. Would you mind telling me the
> differences between Avalon and Fulcrum/Commons.
>
> I just wasn't aware of Avalon for some reason. I've
> been submerged in Turbine, Torque, Fulcrum and Commons
> code.
Honestly, I can only tell you what Avalon does (I wrote
the code for the DB pooling). I don't know what Fulcrum
is much less what it does. As for Commons, I have only
had a cursory look at it, so I am not the one to answer this.
>
> Thanks,
> Randy
> --- Berin Loritsch <bl...@apache.org> wrote:
>
>>Randy Speh wrote:
>>
>>
>>>I would be very interested to see what your
>>>
>>connection
>>
>>>pooling code looks like. I been trying to choose
>>>
>>the
>>
>>>most appropriate connection pooling technique and
>>>
>>have
>>
>>>been considering adapting one myself. Although,
>>>
>>I'd
>>
>>>really rather use something from the open source
>>>community.
>>>
>>>
>>
>>Currently there is dbcp in Commons, Turbine
>>connection pooling,
>>and Avalon connection pooling.
>>
>>Both DBCP and Avalon provide similar semantics
>>inspired by
>>the official JDBC DataSource specifications--when
>>you "close"
>>the connection, it returns the Connection to the
>>pool. Turbine
>>(if I recall) makes you explicitly return it to the
>>pool yourself.
>>
>>I won't get involved with which is the best pattern.
>>
>>Beyond that basic difference, there is alot of
>>difference in the
>>manner that the connection pools are configured.
>>Since I don't
>>have any real information on DBCP and Turbine
>>pooling, I won't
>>talk about them. Here is what Avalon's
>>Configuration looks like:
>>
>><connection>
>> <pool-controller min="2" max="10" grow="2">
>> <keep-alive>SELECT 1 FROM DUAL</keep-alive>
>> </pool-controller>
>>
>> <driver>oracle.jdbc.driver.OracleDriver</driver>
>>
>><dburl>jdbc:oracle:thin:@localhost:1521:ORCL</dburl>
>> <user>scott</user>
>> <password>tiger</password>
>></connection>
>>
>>The Pool Controller specifies how many connections
>>the pool starts
>>with ("min"), the absolute maximum number of
>>connections ("max"),
>>and how many new connections it creates at a time
>>when it needs
>>more ("grow"). It is important to note that the
>>maximum is absolute.
>>The pool will not go beyond that maximum number.
>>The reason being
>>that some drivers have license restrictions and it
>>helps the pool
>>to not violate the license. The last part
>>("keep-alive") is the
>>query used by the pool to determine if the
>>connection has been closed
>>by the server. We found out that not all databases
>>are created
>>equal, and while "SELECT 1" works for many
>>databases, Oracle requires
>>that "1" be selected from the dummy table "DUAL",
>>and others like
>>Informix require you to select from an application's
>>table.
>>
>>You can determine for yourself if this is
>>desirable--and possibly
>>DBCP might steal ideas to narrow the differences.
>>Who knows....
>>
>>
>>--
>>
>>"They that give up essential liberty to obtain a
>>little temporary safety
>> deserve neither liberty nor safety."
>> - Benjamin Franklin
>>
>>
>>--
>>To unsubscribe, e-mail:
>><ma...@jakarta.apache.org>
>>For additional commands, e-mail:
>><ma...@jakarta.apache.org>
>>
>
>
> __________________________________________________
> Do You Yahoo!?
> Send your FREE holiday greetings online!
> http://greetings.yahoo.com
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
> .
>
>
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Database Connection Pool
Posted by Paulo Gaspar <pa...@krankikom.de>.
My code is a mix of DBCP with a bit of learning from
PoolMan.
Neither Avalon nor DBCP wrap all Statement and ResultSet
interfaces and make sure it is impossible for them to be
used after their Connection is returned to the pool.
Avalon does nothing in that direction and DBCP is in
this respect still a bit incomplete (or was when I
forked).
This allows incorrect use to mess with the pool and the
behavior of the Connections. It also makes it hard to
implement a timeout policy for active Connection's,
which sometimes is quite useful.
Besides, I missed a bit more of control over the pace
and the way the Pool grows and shrinks.
(You only need to wrap the ResultSet for JDBC drivers
incorrectly implemented. Closing the Statement should
close the ResultSet.)
As in Avalon and in DBCP, there is a separate generic
pool that is used to implement the database pool. It
also uses the standard DataSource and Connection
interfaces.
There is neither Statement nor ResultSet caching. In
my experience ( <= read this as "with the stuff I do")
I find no big performance gain in caching Statements
and I believe that ResultSets should be cached
elsewhere.
Anyway, if you are looking for the ideal Database Pool
implementations you should also take a look at PoolMan:
http://www.codestudio.com/
It is LGPL and it is not perfect, but even when this
is an obstacle you can always learn a lot from it.
Have fun,
Paulo Gaspar
http://www.krankikom.de
http://www.ruhronline.de
> -----Original Message-----
> From: Randy Speh [mailto:rwspeh@yahoo.com]
> Sent: Thursday, December 27, 2001 8:14 PM
>
>
> Thanks for the info. Would you mind telling me the
> differences between Avalon and Fulcrum/Commons.
>
> I just wasn't aware of Avalon for some reason. I've
> been submerged in Turbine, Torque, Fulcrum and Commons
> code.
>
> Thanks,
> Randy
> --- Berin Loritsch <bl...@apache.org> wrote:
> > Randy Speh wrote:
> >
> > > I would be very interested to see what your
> > connection
> > > pooling code looks like. I been trying to choose
> > the
> > > most appropriate connection pooling technique and
> > have
> > > been considering adapting one myself. Although,
> > I'd
> > > really rather use something from the open source
> > > community.
> > >
> >
> >
> > Currently there is dbcp in Commons, Turbine
> > connection pooling,
> > and Avalon connection pooling.
> >
> > Both DBCP and Avalon provide similar semantics
> > inspired by
> > the official JDBC DataSource specifications--when
> > you "close"
> > the connection, it returns the Connection to the
> > pool. Turbine
> > (if I recall) makes you explicitly return it to the
> > pool yourself.
> >
> > I won't get involved with which is the best pattern.
> >
> > Beyond that basic difference, there is alot of
> > difference in the
> > manner that the connection pools are configured.
> > Since I don't
> > have any real information on DBCP and Turbine
> > pooling, I won't
> > talk about them. Here is what Avalon's
> > Configuration looks like:
> >
> > <connection>
> > <pool-controller min="2" max="10" grow="2">
> > <keep-alive>SELECT 1 FROM DUAL</keep-alive>
> > </pool-controller>
> >
> > <driver>oracle.jdbc.driver.OracleDriver</driver>
> >
> > <dburl>jdbc:oracle:thin:@localhost:1521:ORCL</dburl>
> > <user>scott</user>
> > <password>tiger</password>
> > </connection>
> >
> > The Pool Controller specifies how many connections
> > the pool starts
> > with ("min"), the absolute maximum number of
> > connections ("max"),
> > and how many new connections it creates at a time
> > when it needs
> > more ("grow"). It is important to note that the
> > maximum is absolute.
> > The pool will not go beyond that maximum number.
> > The reason being
> > that some drivers have license restrictions and it
> > helps the pool
> > to not violate the license. The last part
> > ("keep-alive") is the
> > query used by the pool to determine if the
> > connection has been closed
> > by the server. We found out that not all databases
> > are created
> > equal, and while "SELECT 1" works for many
> > databases, Oracle requires
> > that "1" be selected from the dummy table "DUAL",
> > and others like
> > Informix require you to select from an application's
> > table.
> >
> > You can determine for yourself if this is
> > desirable--and possibly
> > DBCP might steal ideas to narrow the differences.
> > Who knows....
> >
> >
> > --
> >
> > "They that give up essential liberty to obtain a
> > little temporary safety
> > deserve neither liberty nor safety."
> > - Benjamin Franklin
> >
> >
> > --
> > To unsubscribe, e-mail:
> > <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> > <ma...@jakarta.apache.org>
> >
>
>
> __________________________________________________
> Do You Yahoo!?
> Send your FREE holiday greetings online!
> http://greetings.yahoo.com
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Database Connection Pool
Posted by Randy Speh <rw...@yahoo.com>.
Thanks for the info. Would you mind telling me the
differences between Avalon and Fulcrum/Commons.
I just wasn't aware of Avalon for some reason. I've
been submerged in Turbine, Torque, Fulcrum and Commons
code.
Thanks,
Randy
--- Berin Loritsch <bl...@apache.org> wrote:
> Randy Speh wrote:
>
> > I would be very interested to see what your
> connection
> > pooling code looks like. I been trying to choose
> the
> > most appropriate connection pooling technique and
> have
> > been considering adapting one myself. Although,
> I'd
> > really rather use something from the open source
> > community.
> >
>
>
> Currently there is dbcp in Commons, Turbine
> connection pooling,
> and Avalon connection pooling.
>
> Both DBCP and Avalon provide similar semantics
> inspired by
> the official JDBC DataSource specifications--when
> you "close"
> the connection, it returns the Connection to the
> pool. Turbine
> (if I recall) makes you explicitly return it to the
> pool yourself.
>
> I won't get involved with which is the best pattern.
>
> Beyond that basic difference, there is alot of
> difference in the
> manner that the connection pools are configured.
> Since I don't
> have any real information on DBCP and Turbine
> pooling, I won't
> talk about them. Here is what Avalon's
> Configuration looks like:
>
> <connection>
> <pool-controller min="2" max="10" grow="2">
> <keep-alive>SELECT 1 FROM DUAL</keep-alive>
> </pool-controller>
>
> <driver>oracle.jdbc.driver.OracleDriver</driver>
>
> <dburl>jdbc:oracle:thin:@localhost:1521:ORCL</dburl>
> <user>scott</user>
> <password>tiger</password>
> </connection>
>
> The Pool Controller specifies how many connections
> the pool starts
> with ("min"), the absolute maximum number of
> connections ("max"),
> and how many new connections it creates at a time
> when it needs
> more ("grow"). It is important to note that the
> maximum is absolute.
> The pool will not go beyond that maximum number.
> The reason being
> that some drivers have license restrictions and it
> helps the pool
> to not violate the license. The last part
> ("keep-alive") is the
> query used by the pool to determine if the
> connection has been closed
> by the server. We found out that not all databases
> are created
> equal, and while "SELECT 1" works for many
> databases, Oracle requires
> that "1" be selected from the dummy table "DUAL",
> and others like
> Informix require you to select from an application's
> table.
>
> You can determine for yourself if this is
> desirable--and possibly
> DBCP might steal ideas to narrow the differences.
> Who knows....
>
>
> --
>
> "They that give up essential liberty to obtain a
> little temporary safety
> deserve neither liberty nor safety."
> - Benjamin Franklin
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
__________________________________________________
Do You Yahoo!?
Send your FREE holiday greetings online!
http://greetings.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Database Connection Pool
Posted by Berin Loritsch <bl...@apache.org>.
Randy Speh wrote:
> I would be very interested to see what your connection
> pooling code looks like. I been trying to choose the
> most appropriate connection pooling technique and have
> been considering adapting one myself. Although, I'd
> really rather use something from the open source
> community.
>
Currently there is dbcp in Commons, Turbine connection pooling,
and Avalon connection pooling.
Both DBCP and Avalon provide similar semantics inspired by
the official JDBC DataSource specifications--when you "close"
the connection, it returns the Connection to the pool. Turbine
(if I recall) makes you explicitly return it to the pool yourself.
I won't get involved with which is the best pattern.
Beyond that basic difference, there is alot of difference in the
manner that the connection pools are configured. Since I don't
have any real information on DBCP and Turbine pooling, I won't
talk about them. Here is what Avalon's Configuration looks like:
<connection>
<pool-controller min="2" max="10" grow="2">
<keep-alive>SELECT 1 FROM DUAL</keep-alive>
</pool-controller>
<driver>oracle.jdbc.driver.OracleDriver</driver>
<dburl>jdbc:oracle:thin:@localhost:1521:ORCL</dburl>
<user>scott</user>
<password>tiger</password>
</connection>
The Pool Controller specifies how many connections the pool starts
with ("min"), the absolute maximum number of connections ("max"),
and how many new connections it creates at a time when it needs
more ("grow"). It is important to note that the maximum is absolute.
The pool will not go beyond that maximum number. The reason being
that some drivers have license restrictions and it helps the pool
to not violate the license. The last part ("keep-alive") is the
query used by the pool to determine if the connection has been closed
by the server. We found out that not all databases are created
equal, and while "SELECT 1" works for many databases, Oracle requires
that "1" be selected from the dummy table "DUAL", and others like
Informix require you to select from an application's table.
You can determine for yourself if this is desirable--and possibly
DBCP might steal ideas to narrow the differences. Who knows....
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Database Connection Pool
Posted by Randy Speh <rw...@yahoo.com>.
I would be very interested to see what your connection
pooling code looks like. I been trying to choose the
most appropriate connection pooling technique and have
been considering adapting one myself. Although, I'd
really rather use something from the open source
community.
Randy Speh
--- Paulo Gaspar <pa...@krankikom.de> wrote:
> With so many reference to database connection pools
> I have to ask:
> - Are you not happy with DBCP?
>
> Things I miss on DBCP:
> - The wrapping is not complete;
> - Not enough pool behavior control;
> - No easy way of closing all Statements and
> ResultSets related to a
> Connection.
>
> So, I was NOT happy with DBCP and what I wanted to
> change was too
> much to make it just by posting patches. So I built
> one, learning
> from DBCP and using lot of its code in the process.
>
> And I could use some more pairs of hands and eyes to
> improve it and
> make sure there are no further bugs (it already has
> some full days
> of testing). Also, I am still not happy with some
> details and could
> use other's opinions.
>
> So I would like to contribute it to the commons. If
> you want to
> take a look I will post it as I am doing with the
> logging stuff.
>
> I am asking because it will still take some hours to
> make sure it
> works alone (without the rest of the framework). If
> you all love
> DBCP and do not care to spend time looking at other
> stuff I can
> save that time.
>
> (Anyway, I am starting to divide some of my stuff
> into subprojects
> and I will end up isolating this one too one of
> these days.)
>
>
> Differences from DBCP:
> - Complete wrapping, providing the possibility to
> close all the
> Statements and ResultSets depending of a
> Connection;
>
> - Possibility of closing all the Connections
> (hence Statements
> and ResultSets too) of a "client" DataSource -
> you can have a
> "server" DataSource that wraps the pool and a
> "client"
> DataSource that you can use for a thread (like
> in a Servlet)
> and close at the end of its use (like at the end
> of processing
> a Servlet request). This helps to ensure proper
> cleaning up;
>
> - More control over the Pool behavior (how it
> grows and how it
> shrinks);
>
> - Different underlying Pool;
>
> - NO Keyed Pools (my poor brain gets confused with
> those) and NO
> statement caching (IMHO too much complexity for
> such low gain);
>
> - Possibility of using a thread pool for the
> cleanup stuff.
>
>
> BTW: it works.
>
> Please tell me if you are curious to see it.
>
>
> Thanks and have fun,
> Paulo Gaspar
>
>
> > -----Original Message-----
> > From: Vincent Massol [mailto:vmassol@octo.com]
> > Sent: Saturday, December 22, 2001 8:09 PM
> > To: commons-dev@jakarta.apache.org
> > Cc: avalon-dev@jakarta.apache.org
> > Subject: Synergies between Avalon and Commons
> projects ?
> >
> >
> > I'd like to have your opinion on the possible
> synergies between Avalon
> > and the Commons projects on reuse and sharing.
> >
> > Here are some of my thoughts :-)
> >
> > * Avalon is a service framework (ok, component and
> service framework)
> > and is suited for lots of projects but some
> projects may not need/want
> > to use the small Avalon wrapper which is layered
> on top of the java
> > classes and may want to use directly the
> implementation (like using a
> > jdbc pool but not as an Avalon component which
> needs to be managed by a
> > component manager)
> >
> > * On the other hand, Commons is geared towards
> providing context neutral
> > libraries which could be used in any context.
> >
> > * Thus, one solution could be to put in Commons
> the bare implementation
> > (like the jdbc pool implementation) and put in
> Avalon a component
> > wrapper on top of it (and reference the commons
> jars).
> >
> > ...
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
__________________________________________________
Do You Yahoo!?
Send your FREE holiday greetings online!
http://greetings.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Database Connection Pool
Posted by Paulo Gaspar <pa...@krankikom.de>.
With so many reference to database connection pools I have to ask:
- Are you not happy with DBCP?
Things I miss on DBCP:
- The wrapping is not complete;
- Not enough pool behavior control;
- No easy way of closing all Statements and ResultSets related to a
Connection.
So, I was NOT happy with DBCP and what I wanted to change was too
much to make it just by posting patches. So I built one, learning
from DBCP and using lot of its code in the process.
And I could use some more pairs of hands and eyes to improve it and
make sure there are no further bugs (it already has some full days
of testing). Also, I am still not happy with some details and could
use other's opinions.
So I would like to contribute it to the commons. If you want to
take a look I will post it as I am doing with the logging stuff.
I am asking because it will still take some hours to make sure it
works alone (without the rest of the framework). If you all love
DBCP and do not care to spend time looking at other stuff I can
save that time.
(Anyway, I am starting to divide some of my stuff into subprojects
and I will end up isolating this one too one of these days.)
Differences from DBCP:
- Complete wrapping, providing the possibility to close all the
Statements and ResultSets depending of a Connection;
- Possibility of closing all the Connections (hence Statements
and ResultSets too) of a "client" DataSource - you can have a
"server" DataSource that wraps the pool and a "client"
DataSource that you can use for a thread (like in a Servlet)
and close at the end of its use (like at the end of processing
a Servlet request). This helps to ensure proper cleaning up;
- More control over the Pool behavior (how it grows and how it
shrinks);
- Different underlying Pool;
- NO Keyed Pools (my poor brain gets confused with those) and NO
statement caching (IMHO too much complexity for such low gain);
- Possibility of using a thread pool for the cleanup stuff.
BTW: it works.
Please tell me if you are curious to see it.
Thanks and have fun,
Paulo Gaspar
> -----Original Message-----
> From: Vincent Massol [mailto:vmassol@octo.com]
> Sent: Saturday, December 22, 2001 8:09 PM
> To: commons-dev@jakarta.apache.org
> Cc: avalon-dev@jakarta.apache.org
> Subject: Synergies between Avalon and Commons projects ?
>
>
> I'd like to have your opinion on the possible synergies between Avalon
> and the Commons projects on reuse and sharing.
>
> Here are some of my thoughts :-)
>
> * Avalon is a service framework (ok, component and service framework)
> and is suited for lots of projects but some projects may not need/want
> to use the small Avalon wrapper which is layered on top of the java
> classes and may want to use directly the implementation (like using a
> jdbc pool but not as an Avalon component which needs to be managed by a
> component manager)
>
> * On the other hand, Commons is geared towards providing context neutral
> libraries which could be used in any context.
>
> * Thus, one solution could be to put in Commons the bare implementation
> (like the jdbc pool implementation) and put in Avalon a component
> wrapper on top of it (and reference the commons jars).
>
> ...
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Synergies between Avalon and Commons projects ?
Posted by Ted Husted <hu...@apache.org>.
"Geir Magnusson Jr." wrote:
> It's worked that way a little, one or two things from Turbine, some new ones
> and what appears to be a dismantling of Struts into a lightweight controller
> rather than a web app framework :)
Struts has always been about providing the Front Controller and i18n
messaging implementations that most web applications need, but isn't
provided by Java itself. Struts has never provided a persistence layer,
or logging utilities, or several other "framework" components that can
be found elsewhere. We simply believe that these are things that you
should be able to plug into a framework, and that there are already
plenty to go around ;-)
So, it is true that once we can shift Struts to rely more on the JSPTL
tags than its own, what will be left is a lightweight controller.
Especially since, that in the meantime, we are trying to put new
components into the Commons or Taglibs, rather than trap them in the
Struts CVS. Examples here include the Workflow initiative, the
Validator, and Tiles. People will still use these with the framework,
much as they still use the Digester, BeanUtils, and Collections. But,
that isn't really a dismantling, but simply efforts to keep Struts
component-based, and to keep the product from devolving into a monolith.
But, this is getting a little off-topic ;-)
-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Custom Software ~ Technical Services.
-- Tel +1 716 737-3463
-- http://www.husted.com/struts/
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Synergies between Avalon and Commons projects ?
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
These issues came up when we formed the commons. For example, I was looking
at the connection pooling implementations in and around Jakarta, and none of
the three I could find at the time (Turbine, Struts, Avalon) were packaged
to be used independently.
Some were technically free of their home framework, but still didn't have
docs, examples or clear support/participation channels.
One of the things we hoped that commons would indeed be was a place for
components to live, so that frameworks could share them.
It's worked that way a little, one or two things from Turbine, some new ones
and what appears to be a dismantling of Struts into a lightweight controller
rather than a web app framework :)
We can't force anything, nor do I think we would ever want to. The people
behind the code in each of the projects have to want to both to it as well
as want to support it....
On 12/22/01 2:09 PM, "Vincent Massol" <vm...@octo.com> wrote:
> I'd like to have your opinion on the possible synergies between Avalon
> and the Commons projects on reuse and sharing.
>
> Here are some of my thoughts :-)
>
> * Avalon is a service framework (ok, component and service framework)
> and is suited for lots of projects but some projects may not need/want
> to use the small Avalon wrapper which is layered on top of the java
> classes and may want to use directly the implementation (like using a
> jdbc pool but not as an Avalon component which needs to be managed by a
> component manager)
>
> * On the other hand, Commons is geared towards providing context neutral
> libraries which could be used in any context.
>
> * Thus, one solution could be to put in Commons the bare implementation
> (like the jdbc pool implementation) and put in Avalon a component
> wrapper on top of it (and reference the commons jars).
>
> * Thus, the bare implementation can also be used independently of
> Avalon.
>
> * For example, we could easily provide an Avalon component which would
> wrap around the commons digester, etc.
>
> What do you think ?
>
> If there is an agreement, this should probably be done slowly, one
> library at a time. I guess, I'm not sure about the knowledge both
> projects have of each other. I have been using both and I see a lot of
> possible code reuse/benefits.
>
> Thanks
> -Vincent
>
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
"They that can give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety." - Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>