Connection Singleton
Connection Singleton[ComponentDesignPatterns | CategoryPattern]
Context
Applicability
Problem
Forces
Participants
Structure
Collaborations
Resulting Context
Consequences
Known Uses
Example
Implementation
Sample Code
Related Patterns
[Below is the original pattern and format used; currently we're morphing it to our standard form. -ed.]
Intent
To allow all components in a process to use a single global connection resource for binding to remote services.
Motivation
Suppose you are writing a system that queries a database in response to a request from a Web server (something a cgi-script or Servlet would do). Part of querying a database involves setting up a connection to the database before the query can be executed. Often creating and initializing the connection is the most expensive part of the database query, since a lot of work has to be done and many objects have to be created. Therefore, to reduce this overhead it behooves the programmer to find a way to avoid creating a connection if at all possible. We can solve this problem by applying the GangOfFour SingletonPattern. The Connection class is made a Singleton, so the single connection will be shared by all components.
Related Patterns
ConnectionFlyweight, ConnectionObserver?
Is a ConnectionSingleton a special form of ConnectionFlyweight?
How does the connection get set up between components? Is this a topic for another pattern or set of patterns?
--NatPryce
It depends on what you mean by connection setup. I wouldn't want to get too demented about the scope. A component could be connected with middleware like Iona's Orbix. Could be MQ series. Could be ADO using the Sybase ODBC driver. Or, it could be a local machine connection or even a component model-specific connection like ConnectionPoints in COM. Incoming or outgoing linkage is another consideration.
Getting detailed about the theory or even the practice of establishing the connection and types of connections seems above and beyond the context of CBD. I get the sense that we're covering the connection setup-specific stuff in things like ContainerIndependence and others.
ConnectionSingleton can be good for a bunch of components on the client sharing a connecction; ConnectionFlyweight can be suited for server components being shared by many clients. They seem to naturally fall on separate ends of the client and server roles in distributed component-based environments. Thoughts?
I dont understand what the difference between ConnectionSingleton and Singleton is! A ConnectionSingleton is a Singleton, after all!
Why not use a connection cache class? This would give you the efficiency without imposing the problems of the singleton.
Why not use a ConnectionPool? (probably the same thing as above but a more popular name)
Who is responsible for the connection? What if a client grabs it makes changes to the state, or doesn't give it back? What if the client using the connection hangs, deadlocks, or crashes? Who cleans up the dead connection? What if a client closes the connection?
EditText of this page
(last edited January 16, 2004)
or FindPage with title or text search