If you have any comments or suggestions, please send mail to mgrand@mindspring.com . Synopsis of the design patterns in volume 1 and the patterns in volume 2 are available on a separate page.

Transaction Patterns

• ACID Transaction

Ensure that a transaction will never have any unexpected or inconsistent outcome. You do that by ensuring that the transaction has the ACID properties: atomicity, consistency, isolation and durability.

Related patterns are

• Snapshot
The Snapshot pattern describes techniques for saving and restoring the state of objects. This is the better way to recover from a transaction failure when a transaction involves a long sequence of operations that modify the state of a small number of simple objects.

• Command
The command pattern describes techniques for remembering and undoing a sequence of operations. This is the better way to recover from a transaction failure when a transaction involves a short sequence of operations that modify the state of a large number of complex objects.

• Audit Trail
Logging a sequence of operations to support the Command Pattern is structurally similar to maintaining an audit trail.

• System Testing
The System Testing pattern should be used to ensure the consistency of transactions.

• Unit Testing
The Unit Testing pattern may also help to ensure the consistency of transactions.

• Single Threaded Execution
The Single Threaded Execution Pattern can be used to keep transactions that modify the state of the same object isolated from each other, so that the modifications each transaction makes to the object’s state do not interfere with each other.

• Read/Write Lock
The Read/Write Lock pattern can be used to keep transactions that use the same object isolated from each other while allowing transactions that do not modify the object’s state to execute concurrently.

• Copy on Write Proxy
The Copy on Write Proxy pattern can be used to help ensured the isolation property of transactions. The Copy on Write Proxy is described as part of the write-up of the Proxy pattern in Volume 1.

• Copy Mutable Parameters
The Copy Mutable Parameters pattern can be used to help ensure the isolation property of transactions.

• Return New Objects from Accessor Method
The Return New Objects from Accessor Method pattern (described in Volume 2) can be used to help ensure the isolation property of transactions.
• Cache Consistency
If you directly manage the storage of persistent distributed objects, you may need the Cache Consistency pattern to ensure that the result of a locally initiated read operation matches the current contents of a remote store.

• Decorator
If an object that does not support access controls such as single threaded execution or read/write lock must participate in an ACID transaction, the object’s deficiency can be compensated for by making the TransactionManager access the object through a decorator object.


• Composite Transaction

You want to design and implement transactions correctly and with a minimum of effort. Simple transactions are easier to implement and make correct than complex transactions. Design and implement complex transactions from simpler ACID transactions.

Related patterns are

• ACID Transaction
The Composite Transaction pattern is built on the ACID transaction pattern.

• Command
The Command Pattern can be the basis for an undo mechanism used to undo operations and restore object to the state they were in at the beginning of a transaction.

• Composed Method
The Composed Method pattern is a coding pattern that describes a way of composing methods from other methods that is structurally similar to the way the Composite Transaction pattern composes transactions.

• Lock File
The Lock File pattern can be used to enforce the isolation property for a composite transaction.

• Two Phase Commit
The Two Phase Commit pattern can be used to ensure the ACID properties of a composite transaction composed from simpler ACID transactions.

• Mailbox
When there is a need to ensure the reliability a composite transaction, you will want to take steps to ensure the reliability of the component transactions that constitute it. If the composite transaction is distributed, you will also want to ensure the reliable transmission of messages between the objects that participate in the transaction by such means as the Mailbox pattern.


• Two Phase Commit

If a transaction is composed of simpler transactions distributed across multiple database managers, you want them to either all complete successfully or to all abort, leaving all objects as they were before the transactions. You achieve this by making an object responsible for coordinating the transactions so that they all complete successfully or all abort.

Related patterns are

• ACID Transaction
The Two Phase Commit pattern is used to build composite transactions having the ACID properties from component transactions that have the ACID properties.

• Composite Transaction
The Two Phase Commit pattern is used with the Composite Transaction pattern

• Decorator
The Decorator pattern provides the basis for the organization of the wrapper objects used in the Two Phase Commit pattern.

• Heartbeat
The Heartbeat pattern may be used with the Two Phase Commit pattern to ensure that the Coordinator object is able to detect catastrophic failures of component transactions in a bounded amount of time.


Audit Trail
You need to verify that transactions are being processed correctly and honestly. Maintain an historical record of transactions that have been applied to an object or set of objects. The record should contain enough detail to determine how the objects affected by the transactions reached their current state.

Related patterns are

• ACID Transaction
If the transactions in an historical record do not have the ACID properties, then it may not be possible to unambiguously determine the effect of each transaction on an object.

• Snapshot
The Snapshot pattern provides advice on how to capture the state of an object.

Distributed Architecture Patterns

Shared Object
You have some information or a limited quantity of a resource. You share objects among multiple clients to share encapsulated information or underlying resources. You centrally manage the object sharing with a separate object, so the sharing does not add to the complexity of the objects being shared or the objects sharing them.

Related patterns are

• Static Locking Order
If Client objects work with multiple Manager objects to concurrently access multiple types of Resource objects, it is possible for two client objects to deadlock while waiting for different resources. Client objects should use the Static Locking Order pattern to avoid this sort of deadlock.


• Object Replication
The Object Replication pattern provides a decentralized way for the clients of an object to share information.

• Object Request Broker
The Object Request Broker pattern can be used to allow objects to be shared by remote clients.

• Scheduler
The Scheduler pattern describes a way to schedule access, one client at a time, to shared resources.

• Read/Write Lock
The Read/Write lock pattern is a specialized form of the Scheduler pattern. It allows multiple clients to concurrently have read access to a resource, but only allows exclusive access for a client that modifies the resource.

• Singleton
The Singleton pattern describes classes that have a single instance that may or may not be shared. The Shared Object pattern describes objects that are shared and may have multiple instances.

• Flyweight
If an object has no intrinsic state, then there is generally no need to impose concurrency restrictions on access to the object. The Shared Object pattern is inappropriate for sharing such objects, because it adds unnecessary overhead. The Flyweight pattern (found in Volume 1) describes a way that objects with no intrinsic state can be shared by local clients any concurrency restrictions.


Object Request Broker
Objects in a distributed environment need to call methods of remote objects. For remote calls to work, many details must be just right. Provide an infrastructure that allows objects to make remote calls, with most of the details of the call hidden and handled automatically by the infrastructure.

Related patterns are

• Object Identifier
The Object Identifier pattern provides additional guidance on uniquely identifying possibly remote objects.

• Heartbeat Pattern
The Heartbeat pattern provides a general purpose way to detect when the caller of a remote method will never see the call complete because the machine that the remote call runs on has crashed or the network connection to the remote machine has been lost.

• Registry
The Registry pattern describes a way for an Object Request Broker implementation to find remote objects that have a know name or unique object identifier.

• Thread Pool
An object request broker need a thread to process each remote call. An implementation of the Object Request Broker pattern can use the Thread Pool pattern to recycle threads and avoid the expense of creating new threads.


• Object Replication

You need to improve the throughput or availability of a distributed computation. A distributed computation is a computation that involves objects that reside on multiple computing elements and are able to communicate with each other. In some circumstances, it is possible to improve the availability and throughput of a computation by replicating an object onto multiple computing elements while maintaining the illusion to the object’s clients of there only being a single object.

Related patterns are

• High Availability
The High Availability pattern is a more specialized pattern that describes the use of replication to make objects highly available.
• Optimistic Concurrency
The Optimistic Concurrency pattern describes how to update data without the use of locks.

• Immutable
The Immutable pattern explains the simplicity and safety that comes from designing objects to be immutable.

• Object Request Broker
The Object Request Broker pattern allows an object to be used in multiple places at the same time without it being in multiple places or replicated.


• Redundant Independent Objects

You need to ensure the availability of an object even if it or the platform it is running on experience a failure. You accomplish this by providing redundant objects that do not rely on any single common resource.

Related patterns are

• Prompt Repair
The Prompt Repair pattern is often used with the Redundant Independent Objects pattern to ensure the continued availability of a set of redundant independent objects even after a failure occurs.

• Object Replication
The Redundant Independent Objects pattern is a specialized version of the Object Replication pattern.


• Prompt Repair

When one of a set of redundant independent objects fails, one fewer failures must occur before the entire set of redundant objects becomes unavailable. To minimize the likelihood of a catastrophic failure, repair the failed object as soon as possible.

Related patterns are

• Redundant Independent Objects
The Prompt Repair pattern is use with the Redundant Independent Object pattern.

• Process Pair
The Process Pair pattern is used to ensure that software components on the same computing element are restarted when they fail.

• Snapshot
The Snapshot pattern (described in Volume 1) can be used to implement checkpoint/restart.


• Mobile Agent

An object needs to access very large volume of remote data. To conserve network bandwidth, Instead instead of bringing data to an object, move the object to the data.

Related patterns are:

• Object Request Broker
The Object Request Broker pattern is usually used with the Mobile Agent pattern to facilitate communications between mobile agents and other objects. Mobile agents can be implemented on top of the Object Request Broker pattern.

• Object Replication
One of the applications of the Object Replication pattern is to ensure that an object is near its accessors. The Mobile Agent pattern provides a way for an object’s accessors to be near the object.


• Demilitarized Zone

You don’t want hackers to be able to gain access to servers containing sensitive information if they are able to compromise the security of a publicly accessible server. Put servers that are accessible to the public Internet on a publicly accessible LAN that connects with both between your private network firewall and the public Internet.

Related pattern are

• Protection Proxy
The Protection Proxy pattern, at the object level, is structurally similar to the Demilitarized Zone pattern at the network level.


• Process Pair

To keep a process or software component highly available, you want it to be automatically restarted if it fails. Organize highly available software components in pairs, so that if one fails the other restarts it.

Related pattern are

• Heartbeat
The Process Pair pattern uses the Heartbeat pattern.

Distributed Computing Patterns

• Object Identifier

You need to uniquely identify an object that exists in multiple environments. Assign a globally unique identifier to the object, allowing it to have a unique identity when it is shared between programs or databases.

Related patterns are

• Object Request Broker and Registry
You can use the Object Request Broker pattern with the Registry pattern to encapsulate an implementation of the Object Identifier pattern and minimize the number of classes that are dependent on it.

• Mobile Agent
The Mobile Agent pattern uses the Object ID pattern.

• Object Replication
The Object Replication pattern uses the Object ID pattern.


• Registry

Objects need to contact another object, knowing only the object’s name or the name of the service it provides, but not its how to contact it. Provide a service that takes the name of an object, service or role and returns a remote proxy that encapsulates the knowledge of how to contact the named object.

Related patterns are

• Proxy
The Registry pattern uses the Proxy pattern.

• Object Request Broker
The Registry pattern is often used the Object Request Broker pattern.

• Shared Object
Registry objects are shared objects.


• Protection Proxy

Malicious objects may attempt to violate the integrity of other objects by using reflection or other means to access methods or variables they should not. You can prevent this by requiring other objects to access sensitive objects through a proxy that limits access based on security considerations. The proxy implements measures to ensure that other objects do not gain access to features of a sensitive object that they are not entitled to.

Related patterns are

• Proxy
The Protection Proxy pattern is a specialized version of the Proxy pattern.

• Template Method
The Protection Proxy pattern uses the Template Method pattern to abstract out the reusable portion of the thread management logic.

• Thread Pool
You can use the Thread Pool pattern with the Protection Proxy pattern to create a multi-threaded proxy.


• Publish-Subscribe

You need to provide timely delivery of messages to one or more objects. Deliver messages to subscribed recipient objects by transmitting each message to each recipient. Ensure reliable delivery by repeating the transmission after an attempt fails until delivery is successful.

Related patterns are:

• Object Request Broker
The Publish-Subscribe pattern is often used with the Object Request Broker pattern to deliver messages to remote objects.

• Mailbox
The Mailbox pattern provides an alternate solution for the reliable delivery of messages.

• Registry
The registry pattern provides a way for Subscriber objects to find Publisher objects.
• Retransmission

You need to ensure that an object can reliably send a message to a remote object. Following the maxim, “If at first you don’t succeed, try again”, you design the object to handle a failure to send a message by trying again until the send is successful.

Related patterns are:

• Object Request Broker
The Retransmission pattern is often used with the Object Request Broker pattern to deliver messages to remote objects.

• Mailbox
The Mailbox pattern provides an alternate solution for the reliable delivery of messages.

• High Availability
You can use the High Availability pattern to minimize the likelihood that a DeliveryAgent object will crash or become otherwise unavailable.

• Process Pair
The Process Pair pattern describes a way to ensure that a DeliveryAgent object is automatically restarted after a crash.
• Mailbox

You need to provide reliable delivery of messages to objects. Facilitate the delivery of messages by storing messages for later retrieval by each recipient.

Related patterns are:

• Publish-Subscribe
The Publish-Subscribe pattern provides an alternate solution for the reliable delivery of messages.

• High Availability
The High Availability pattern can be used to ensure that a MailboxServer is highly available.

• Object Request Broker
The Mailbox pattern is often used with the Object Request Broker pattern to deliver messages to remote objects.

• Process Pair
The Process Pair pattern describes a way to ensure that a MailboxServer object is automatically restarted after a crash.

• Registry
The registry pattern provides a way for Subscriber objects to find MailboxServer objects.

• Heavyweight/Lightweight Object

You are designing an application client that should be as small and thin as possible. The client must access some objects that have many attributes and/or attributes that are large objects. The client does not always need the attributes, so you arrange for the client to download the objects without the attributes and then lazily download the attributes on an as needed basis.

Related Patterns are:

• Object Request Broker
The Heavyweight/Lightweight pattern is usually implemented using the Object Request Broker to facilitate communication between the client and the server.

• Lazy Initialization
The lazy Initialization pattern can be used to manage the download of Data objects if client objects are responsible for the download of their own Data object.

• Virtual Proxy
The Virtual Proxy pattern should be used to manage the download of Data objects if the same class is used to implement the client and server version of the shared object.

• Object Replication
The Object Replication pattern addresses issues related to keeping the state of the client and server objects consistent.

• Facade
Like a façade object, a lightweight object hides the details of accessing objects behind it.

• Heartbeat

While a remote object is performing an operation on behalf of a client, periodically send a message back to the client indicating that the remote object is still alive.

Related patterns are:

• Object Request Broker
The Heartbeat pattern is used with the Object Request Broker pattern.

• Connection Multiplexing
Whether or not the ORB being used with the Heartbeat pattern implements the Connection Multiplexing pattern can determine how you choose to implement the Heartbeat pattern.


• Connection Multiplexing

You are designing a distributed system in which one object may establish many connections with another object. To avoid the overhead of setting up and shutting down many connections between the same two objects, you arrange for one actual connection to carry the contents of multiple virtual connections.

Related patterns are

• Object Pool
The Connection Multiplexing pattern uses the Object Pool pattern to manage data buffers.

• Object Identifier
The ConnectionID objects used by the Connection Multiplexing pattern are an application of the Object Identifier pattern.

• Scheduler
The Scheduler pattern can be used to ensure that all virtual connections get their fair share of the actual connection’s bandwidth. The Scheduling pattern describes how to enforce a policy that determines when a thread is scheduled to use a resource.

Concurrency Patterns

• Session Object

A server’s sessions with clients have state information associated with them, but you don’t want to duplicate a lot of objects for each session. Use a single object to contain all the state information needed during a session by the server and make that object accessible to all other objects that need state information for the current session.

Related patterns are

• Singleton
The Singleton pattern (described in Volume 1) uses a single instance of a class for an entire program. The Session pattern uses a single instance of a class per session.

• Thread Pool
You can use the Thread Pool pattern to manage the association between threads and sessions over time.


• Lock File

A program will need to have exclusive access to an external resource. You design the program to check for the existence of a lock file prior to accessing the resource. If the lock file exists, the program does not use the resource. If the lock file does not exist, the program creates the file and then uses the resource.

Related patterns are

• Static Locking Order
The Static Locking Order pattern is used with the Lock File pattern when there are multiple resources to be coordinated, in order to avoid deadlocks.

• ACID Transaction
The lock file pattern may be used in the implementation of the ACID Transaction pattern.


• Static Locking Order

If two objects need exclusive access to the same set of resources, they can become deadlocked with each holding a lock on one resource and waiting for the other to release its resource. You can avoid such deadlocks by ensuring that all objects acquire locks on resources in the same order.

Related patterns are

• ACID Transaction
The Static Locking Order pattern can be used in the design of ACID transactions.

• Lock File
The Static Locking Order pattern can be used with the Lock File pattern to avoid deadlocks.


• Optimistic Concurrency

Improve throughput of transaction processing by not waiting for locks that a transaction will need. Instead, be optimistic and perform the transaction logic on private copies of the records or objects involved. Do insist that the locks be granted before the updates can be committed, but abort the transaction if conflicting updates were made prior to the granting of the locks.

Related patterns are

• ACID Transaction
The Optimistic Concurrency pattern can be used in the implementation of the ACID Transaction pattern.

• Object Replication
The Optimistic Concurrency pattern can be used in the implementation of the Object Replication pattern.


• Thread Pool

The nature of many servers is that they are presented with a steady stream of tasks to perform that must each be performed in their own thread. Creating a thread is a relatively expensive operation. Avoid the expense of creating a thread for each task by reusing threads.

Related patterns are

• Object Pool
The Thread Pool pattern is a specialized form of the Object Pool pattern described Volume 1.

• Factory Method
Implementations of the Thread Pool pattern may use the Factory Method pattern to allow greater flexibility in how they create new threads.

• Singleton
The Singleton pattern is often used with the Thread Pool pattern to ensure that all classes that want to use a ThreadPool object use the same ThreadPool object.

• Guarded Suspension
Implementations of the Thread Pool pattern directly or indirectly use the Guarded Suspension pattern to manage the queuing of tasks.


• Cache Consistency

A cache can be used to keep a local copy of data from a remote data source. From time to time, the content of the data in the remote data source may change. You want a local cache to reflect such changes in a remote data source. Ensure that the data in the local cache matches the remote data source within a bounded amount of time by considering data in a cache to have a maximum useful lifetime.

Related patterns are

• Cache Management
The Cache Consistency pattern is a refinement to the Cache Management pattern. That discussion includes a much more detailed discussion of caching.

• Scheduler
The Cache Consistency pattern uses the Scheduler pattern.

• Heavyweight/LightWeight
Application clients may use the Cache Consistency pattern with the Heavyweight/Lightweight pattern to manage lightweight objects.


• Deep Transaction Nesting

Implement the ability to restore the original state of objects altered by possibly nested atomic transactions by saving the state of an object on a stack. This technique is most commonly used for transactions that only alter local objects or objects that are otherwise cheap to access.

Related patterns are

• ACID Transaction
The ACID Transaction pattern contains more information about the atomic and isolated properties of transactions.

• Decorator
The logic to implement a TransactionParticipantIF interface for a class that participates in a transaction is often implemented using the Decorator pattern.
• Snapshot
The Deep Transaction pattern uses the Snapshot pattern to encapsulate the current state of an object in a way suitable for putting on a stack and possibly being restored later.

Temporal Patterns

• Time Server

In order for some distributed applications to function correctly, the clocks on the computers they run on must be synchronized. Ensure that clocks on multiple computers are synchronized by synchronizing them with a common clock.

Related patterns are

• Versioned Object
Distributed applications that use the Versioned Object pattern are likely to also use the Time Server pattern.

• Temporal Property
Distributed applications that use the Temporal Property pattern are likely to also use the Time Server pattern.

Versioned Object

You may need to access pervious or future states of an object. When an object gets a new state, keep both the object’s new state and its previous states. Identify the states by a timestamp or a version number. Allow access to a specific state of an object by identifying its timestamp or version number.

Related patterns are

• Time Server
The Versioned Object pattern is often used in conjunction with the Time Server pattern to ensure consistent timestamping of object versions.

• Virtual Proxy
The Virtual Proxy pattern is sometimes used with the Versioned Object pattern to avoid having to load all the states of an object from a persistent store.

• Temporal Property
The Temporal Property pattern provides a alternate way of organizing changes in an object’s state over time. It is more appropriate for classes whose state changes tend to involve only one attribute at a time.

Temporal Property

The values of an object’s attributes may change over time. They usually change independently of each other. Keep historical values of attributes in a way that allows clients to get the effective value of a particular attribute as of a particular time.

Related patterns are

• Time Server
The Temporal Property pattern is often used in conjunction with the Time Server pattern to ensure consistent timestamping of property values.

• Versioned Object
The Versioned Object pattern provides a alternate way of organizing changes in an object’s state over time. It is more appropriate for classes whose state changes tend to involve changes to multiple attributes.

Database Patterns

• Persistence Layer

Keep the details of persisting objects and dependencies on a specific kind of database out of application specific classes. Do this by organizing persistence related details into classes that make up a persistence layer. Design application classes to perform all persistence operations through the persistence layer.

Related patterns are

• Virtual Proxy
The Virtual Proxy pattern, described in Volume 1, may be used by an implementation of the Persistence Layer pattern to defer the fetching of objects that are part of a more complex object but may not be needed for some uses of the complex object.

• CRUD
The CRUD pattern is used to design interfaces for the Persistence pattern for objects responsible for persisting business objects.

• Stale Object
The Stale Object pattern is used with the Persistence Layer pattern to ensure the consistency of updates.

• Change Manager
The Change Manager pattern is often used with the persistence pattern in order to determine, based on the state of an object whether it needs to be written to the persistent store or not.

• Object ID Manager
The Object ID Manager pattern is used with the Persistence Layer pattern to generate object IDs that will be unique across all domains that an object will be used in or from.

• Transaction Manager
The Persistence layer pattern uses the Transaction Manager pattern to manage transactions.

• Connection Manager
The Connection Manager pattern is used in implementing the Persistence Layer pattern.

• Abstract Factory
The Persistence Layer pattern uses the Abstract Factory pattern to encapsulate the selection of a persistent store and to ensure that the persister objects that are used are all for the correct persistent store.

• Cache Management
The Cache Management pattern, described in Volume 1, is used with the Persistence Layer pattern to avoid unnecessary fetches from the persistent store.

• Cache Consistency
The Cache Consistency pattern may be used by a persistence layer to implement guarantees on how current the objects in a cache are.

• Singleton
The Persistence Layer pattern uses the Singleton pattern to manage instances of classes.

• Marker Interface
The Persistence Layer pattern uses the Marker Interface pattern to recognize objects that are instances of classes that it may persist.


• CRUD

Organize the persistence operations of an application into Create, Retrieve, Update and Delete operations that are implemented by a persistence layer.

Related patterns are

• Object Identifier
Implementations of CRUD interfaces use the Object Identifier pattern to identify objects in memory and in databases.

• Object ID Manager
The Object ID Manager pattern is used with the CRUD pattern to generate object IDs that will be unique across all domains that an object will be used in or from.

• Persistence Layer
The CRUD pattern is used by the Persistence Layer Pattern.

• Stale Object
The Stale Object pattern is used when implementing the CRUD pattern to ensure the consistency of updates.
• Stale Object

A program may have multiple in-memory copies of a persisted object. These copies may have been retrieved from the database at different times and reflect different states of the object. A relatively common yet difficult to diagnose bug is to update the persisted object using an obsolete copy of the object. Use cached information about the most recently retrieved version of an object to ensure that updates to it are based on the current version of the object.

Related patterns are

• PersistenceLayer
The Stale Object design pattern is used in designing the implementation of the Persistence Layer architectural pattern.

• CRUD
The Stale Object design pattern is used with the CRUD pattern in designing classes that are responsible for persisting specific kinds of objects for an application.


• Type Conversion

If the values in a persisted object in a database are represented differently than the values in in-memory objects, then some type conversions will need to be done. Organize the methods that perform the conversions into type conversion classes.

Related patterns are

• CRUD
The Type Conversion design pattern is used in designing implementations of the CRUD architectural pattern.


• Intention Revealing Method
The Type Conversion pattern is often an application of the Intention Revealing Method described in Volume 2.


• isDirty

Avoid the expense of updating objects in a database that don’t need to be updated by keeping track of whether they actually do need to be updated.

Related patterns are

• PersistenceLayer
The isDirty pattern can be used with the Persistence Layer pattern.


• Lazy Retrieval
  

If the design of a program involves persisted complex objects, you may find a persistence layer having to move large numbers of related objects in and out of a database all at once. If they are not all needed at once, then delay the retrieval of portions of complex objects until they are needed.

Related patterns are

• isDirty
The isDirty pattern is often used with the Lazy Retrieval pattern to avoid unnecessary update operations for a complex object’s associated objects.


• Lazy Initialization
The Lazy Retrieval pattern is a specialized version of the Lazy initialization pattern described in Volume 2

• Object Identifier

An implementation of the Lazy Retrieval pattern may use the Object Identifier pattern to identify an object that is associated with a complex object but not yet retrieved from the database.

Return to Mark Grand's home page.