Connection Singleton

[ComponentDesignPatterns | CategoryPattern]

Context

Applicability

Problem

Forces

Solution

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?

PhilipEskelin

I dont understand what the difference between ConnectionSingleton and Singleton is! A ConnectionSingleton is a Singleton, after all!

DavidPlass

Why not use a connection cache class? This would give you the efficiency without imposing the problems of the singleton.

--AsimJalis

Why not use a ConnectionPool? (probably the same thing as above but a more popular name)

--JohnHarby

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)
FindPage by browsing or searching

This page mirrored in ComponentDesignPatterns as of April 29, 2006