Stateless session EJBs are ideal for this kind of functionality.
But that requires that you use EJBs in your design. However, if your application is
bottlenecked by Singletons then it is clear that you need middle-tier components
anyway (and if your web-tier is written in Java, EJB is the best choice for
middle-tier).
inder
----
J2EE Application Programming Model
Java Software, Sun Microsystems Inc.
Ted Neward wrote:
>
> Something that folks might also want to consider is the fact that Singletons
> provide a bottleneck or chokepoint for heavily-laden multithreaded
> servers--if everybody has to go to the same object to obtain the Connection,
> then (a) the Singleton had better DAMN well be debugged for synchronous
> access (and folks, this is harder to do than it sounds), and (b) the
> Singleton had better DAMN well be fast.
>
> In many cases, where folks want to use a Singleton, a variety of *other*
> patterns can be used--an Object Pool, for example, or a Product Trader
> pattern, or even a "create-on-request/destroy-on-release" pattern (from the
> COM/MTS world). And before you start to flame me about wasting resources and
> so forth, remember that the JDBC 2.0 Specification calls for Connection
> pooling to take place "under the hood" of the Specification itself, so that
> users of the JDBC API no longer have to worry about it. (Section 3.6, JDBC
> 2.0 API Spec, by Seth White and Mark Hapner. Part of the standard JDK 1.2
> documentation bundle.)
>
> Singleton is probably, IMHO, one of the most over-abused patterns of the
> entire GOF book (alongside the ubiquitous "Factory" pattern, which really
> isn't a pattern by itself, but a collection of about six independent
> patterns). Many designs that utilize a Singleton don't really need one--they
> just need an object that provides some functionality for them (such as a
> database connection) to be around when they need it, which is only half of
> Singleton's Intent. Unless the Singleton must maintain state (which most
> Connections don't), the Singleton doesn't need to be a Singleton.
>
> Ted Neward
> Patterns/C++/Java/CORBA/EJB/COM-DCOM spoken here
> http://www.javageeks.com/~tneward
> "I don't even speak for myself; my wife won't let me." --Me
>
> -----Original Message-----
> From: Dmitri Namiot <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
> Date: Thursday, September 02, 1999 2:09 PM
> Subject: Re: Global ConnectionPool Servlet
>
> >thank you Craig. I must say my question was a bit provocate,
> >we are using our own session/connection stuff a long time ago
> >(as soon as we faced implementation bugs in the different servlets
> >engines), but I think your long letter contains a pretty good
> >explanation for all alternatives.
> >
> >
> >P.S. Except some remarks about O-O style, but that so flame ready
> >topic and it would be better for me do not touch this at all :-)
> >
> >>Sure, you can create a connection pool object dynamically using
> >>Class.forName()
> >> or whatever.
> >> The singleton pattern (using a static method) can work, as long as you
> >>only ever
> >> need one
> >> connection pool. But, what happens when you need TWO of them? (And it
> >>might
> >> not be you that
> >> needs the second -- it might be another application running in the
> >same
> >servlet
> >> engine as
> >> you)
> >
> >> OPTION 1 -- If you use the "static method" approach like this:
> >
> >> public class ConnectionPool {
> >>
> >> public static Connection getConnection() { ... }
> >>
> >> ....
> >
> >> }
> >
> > then you've got a singleton pattern implementation, and you can't have
> two
> > different ones
> > (unless you try to embed that logic in your singleton connection pool,
> >which
> > doesn't seem
> >
> >ColdJava: java server side programming
> >http://coldjava.hypermart.net
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
