From: Clark C . Evans <cce@cl...> - 2001-10-24 19:29:30
I like the "Kit" (mix-in) approach mentioned by Tom,
this would keep the database access code properly out
of the WebKit core.
That said, I understand the problem with the
funcitonality that belongs in the Application
object. Right now my application isn't cleaning
up database connections (yuck!). Perhaps there
could be a "clean-up" registration function added?
This way other processes could be run when the
AppServer shuts down?
The problem I have in general is that database connectivity
is not a simple goal that has the same form for all
applications. For instance, I have multiple databases,
each with a well-known user and password. Alternatively,
I'm sure that there is someone with a multiple-user
approach... who wants the database to enforce security.
Or possibly even a multi-database multiple-user approach.
The approach you are providing is too simplistic for
me... although it may work for many others.
On Wed, Oct 24, 2001 at 09:16:00PM +0200, Tom Schwaller wrote:
| Ken Lalonde wrote:
| > Thanks for your comments, Clark.
| > I'd argue for putting Application.getDbConnection() in the core
| > as follows:
| > - putting it in SitePage makes it inaccessible
| > to code that doesn't subclass SitePage.
| > For example, I keep WebKit session data in a postgresql database,
| > and the code to implement that is unrelated to SitePage.
| > The pool is logically part of the application, not the Page servlet.
| > - cleaning up DB connections at exit time is more awkward
| > when subclassing SitePage. I guess you can do it with atexit,
| > but it's messy, and some people won't bother.
| > - it took me a little fiddling around to figure out the best way
| > to do pooling connections, and I imagine others will
| > waste time reinventing the same thing.
| > Providing an application-wide connection pool with proper
| > cleanup at exit fills a very common developer need,
| > and is appropriate for the core.
| I personally agree to put this into the core, since it is probably the
| first thing
| people will use when developing dynamic web applications with Webware.
| I was never really happy with the situation to implement this kind
| of stuff myself.
| The other possibility would be a small DBKit, which does the same thing
| and makes available some more convenience routines (some of them
| on this mailinglist some time ago). I used this kind of approach a long
| time ago
| and switched to the "Derive from SitePage" approach later, but a cleaner
| solution would be nice. Maybe even a PoolKit, which makes pooling
| in a much general sense (like Poolman in the Java world,
| Tom Schwaller