Hello Berin and All!
Back from a long delay :-))
Just of curiosity wanted to comment a bit!
Hay Bruce wrote:
HB> I would like to develop a connection pool to a back-end server which has
HB> an SMTP like interface. This would be deployed in Tomcat/cocoon in an
HB> analagous way to a database connection pool i.e. I'd like to hold open a
HB> collection of sockets which could be (re)used. Could anyone give me some
HB> pointers on how this would be implemented in the
HB> Avalon/Excalibur/Fortress/... world?
Bering Loritsch wrote:
BL> I would look at the Database component's way of doing something similar.
BL> There are a couple approaches to pooling objects:
BL> * Explicit pooling--the user has to acquire and release a handle explicitly.
BL> This is similar to the ServiceManager approach.
BL> * Implicit pooling--the backend pool is used when the user calls the "close"
BL> method. This is similar to the way javax.sql.DataSource
BL> pools modify the java.sql.Connection.close() semantics.
BL> * Garbage Collection--the user has no control over the reclamation of the
BL> socket. They are given certain guarantees as to
BL> how the connection would operate, but there is no
BL> guarantee that the connection originally aquired is
BL> the same as the one used toward the end of the
BL>
transaction.
Hmm :-) What's this? Is this that the user is given just a wrapper,
and for every real call the in the wrapper
doSmth(x){
conn = realPool.get();
conn.doSmth(x);
realPool.release(conn)
}
BL> The exact mechanism would have to fit the use case. As a matter of general
BL> style, I would stay away from explicit pooling if you can help it. Implicit
BL> pooling is orders of magnitude easier to implement than garbage collecting.
Well, if you really have an established interface, like
java.sql.Connection this is certainly the case.
But if you're drafting a new interface, what's the difference between
explicit and implicit? Only as followes?
Implicit:
conn = provider.getConn();
...
conn.close();
Explicit:
conn = provider.getConn();
...
provider.release(conn)
Aren't these two really almost the same?
If yes, I would even probably prefer Implicit, probably just because
this is more ServiceManager-like :-) And because this liberates
the connection from remembering its parent. This is because this
pattern has been chosen for ServiceManager, isn't it?
BL> The JdbcDataSource in the Avalon database connection pool uses
BL> implicit pooling, and it works fairly well.
Yes, the DBCP code, especially BasicDataSource is a good example.
As to the pool-living-in-avalon container, here are my thoughts, Hay:
In J2EE world you have JNDI to glue everything together.
(And everyone has access almost to everything, that's where
Avalon is seen as being stronger :)
In Avalon you have a ServiceManager you use to grab your
dependencies from.
Therefore, while in J2EE world you would seek a way to
* bind your pool to JNDI
to make it accessible for clients, in Avalon you will
* make the pool be a component
* implementing some
public interface MyServiceSource{
String ROLE = MyServiceSource.class.getName();
MyService getMyService();
}
* be configured and delivered to clients
via regular Avalon configuration mechanisms
Yes, while the connection itself might have been a component
(and be pooled by the Avalon internal mechanisms) I think
that the pool is a better candidate for a component, isn't it,
(hey, all?)
Now, we have to code the implementation of MyServiceSource.
Berin, what would we recommend as the internal pool implementation?
Should we probably recommend commons-pool?
In fact it has many configuration parameters and wrapping it into
MyServiceSourceImpl will make it _very_ easy to be configured
(yes, here's where Avalon is really strong :-)
The only thing that worries me a bit in this scenario is that
each commons-pool instance will probably create its own
worker thread if eviction feature is used (killing connections
that are too old) or maybe under some other circumstances.
But maybe this is all okay.
Anyway, my $0.02
(As the matter of fact I have been thinking about doing similar
things myself, hence I wanted to comment)
-Anton
--
Best regards,
Anton mailto:[EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
