No argument there. :)
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: Inderjeet Singh <[EMAIL PROTECTED]>
To: Ted Neward <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Date: Monday, September 06, 1999 9:53 AM
Subject: Re: Global ConnectionPool Servlet
>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
