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) }
Not necessarily. For Garbage collection, you are given a wrapper (you got that much right). The instance stays with the wrapper for a period of time, unless the pool needs to reclaim it for some reason. After it is reclaimed, if the current client needs to perform more actions, the wrapper grabs a another instance.
There are certain complexities with this in that we can't break up transactions, and time-limits, etc. are somewhat hard to predict. Granted when you have a limited resource (like a number of JDBC connections to a database with license limitations) it does allow you to share the connections at a higher granularity.
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?
Almost. The main difference is _where_ the connection is released. With the implicit version, it is not necessarily obvious that the connection is pooled. In the explicit version, it is very obvious.
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?
Actually the ServiceManager has lookup() and release(), so it is modeled after the explicit model. It does complicate matters if you have to be ultra careful to return a resource that you acquired.
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
Which is the javax.sql.DataSource object
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?)
That is pretty much what we did with the DataSourceComponent. It was originally designed with the DataSource interface unavailable in the main JRE, so I created a dumbed down version for Avalon. You acquire the DataSourceComponent (possibly in the future this will be replaced by javax.sql.DataSource itself) and get your individual connections that way.
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)
Anything is possible, and we don't want to force any one way of doing things on anybody. All we can do is put out there what we have learned, and talked about. I honestly would like to see a working implementation of the Garbage Collection approach, but so far we have not been able to do that.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
