Hut, The important general point about pools is that they normally encapsulate all the work-a-day business of creating connections, and present to the connection consumer a pretty simple contract. Of course theres a lot of information needed to start a pool, but if you, as a mailet user, leave that up to james you are pretty much left with the scenario whereby you say getPool().getConnection() in some form or other, possibly with a choice of pools, and get a java.sql.Connection by return.
Therefore any change in the implementation of the pool may be Big Work (or not) for James developers, but is highly unlikely to mean more than a find-and-replace of boilerplate code for mailet developers. FWIW James is proposing to use jakarta-commons DBCP for the new pooling impl. If you're interested in the world of JDBC connection pooling perhaps a look at it would be educational? d. P.S. If you want another related topic to explore think about cacheing file reads so that frequently read files are read from memory not disc and updated from disc much less frequently to improve performance. d. > -----Original Message----- > From: Hutson Carspecken [mailto:[EMAIL PROTECTED] > Sent: 17 July 2003 20:09 > To: James Users List > Subject: Re: Plans to Shift from Current Connection Pool to Another In > Next Version > > > Noel, > > Thank you for your patience. Everthing is beginning to make > sense now. As > I see it, the ConnectionPoolDataSource object is registered with Avalon > outside of the confines of the mailet, most likely during JAMES start up. > All you do in the mailet is go to established pool and pick up a > connection. > > Terrific. Thanks. > > Hut > ----- Original Message ----- > From: "Noel J. Bergman" <[EMAIL PROTECTED]> > To: "James Users List" <[EMAIL PROTECTED]>; "Hutson Carspecken" > <[EMAIL PROTECTED]> > Sent: Thursday, July 17, 2003 1:51 PM > Subject: RE: Plans to Shift from Current Connection Pool to > Another In Next > Version > > > > A change of connection pool is supposed to be transparent to > client code. > > There will be a non-transparent change in James v3, but that is > simply to > > provide the data source via a different mechanism (probably > JNDI), instead > > of Avalon. > > > > --- Noel > > > > -----Original Message----- > > From: Hutson Carspecken [mailto:[EMAIL PROTECTED] > > Sent: Thursday, July 17, 2003 14:34 > > To: James Users List > > Subject: Plans to Shift from Current Connection Pool to Another In Next > > Version > > > > > > Noel, > > > > I wrote about the connection pool and have since done a considerable > amount > > of reading on the JDBC API implimentation of connection pools. > Thank you, > I > > was farther behind than I expected. > > > > You mentioned that JAMES is moving to another version of connection > pooling. > > As I would like to stay in the realm of JAMES as much as possible, could > you > > please elaborate on that future move? > > > > Hut > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
