Contact Us 1-800-596-4880
  1. Homepage
  2. Mule Runtime (3.2)
  3. Advanced Usage of Mule ESB 3

  4. Mule Object Stores

Mule Object Stores

A object store is an abstraction for storing objects in Mule. By using an object store, Mule is decoupled from any specific store implementation, allowing you to choose or switch the implementation you want.

Mule uses object stores in:

  • services. For SEDA queues, between an inbound and a service component.

  • VM transports. In one-way endpoints only. When using one-way endpoints, messages are delivered to the corresponding inbound endpoint via a queue.

  • Various filters, routers, and other message processors that need to be persistent.

  • Mule 3.2 Flows. Through the queued-asynchronous processing-strategy. See Flow Processing Strategies for more information about the queued-asynchronous processing-strategy.

  • Mule 3.2 Clusters. Mule uses a clustered object store for clusters. The clustered object store is in a shared memory grid

Object Stores Available in Mule

Mule provides two types of default object stores:

  • Default in-memory store. This is where all non-persistent data is stored by default. Mule creates a default in-memory store in memory. However, for a cluster, Mule creates the default in-memory store in the shared memory grid.

  • Default persistent store. This is where all persistent data is stored by default. Mule creates a default persistent store in the file system. However, for a cluster, Mule creates the default persistent store in the shared memory grid.

In most cases, the default object store will meet your needs. In these cases, no configuration is necessary. However, you can specify a queue store for message persistence (a queue store is an object store for queues). For a service’s SEDA queue, you specify the queue store to use by specifying an appropriate child element in the <queue-profile> element. The available queue stores, and their respective elements, are listed in the following table:

queue store description element

queue-store

References the global queue store.

<queue-store>

default in-memory-queue-store

The default in-memory store.

<default-in-memory-queue-store>

default persistent-queue-store

A file-based store. For a cluster, it is the default in-memory store.

<default-persistent-queue-store>

simple in-memory queue-store

Always an in-memory store.

<simple-in-memory queue-store>

file queue store

Always a file-based store.

<file-queue-store>

For example, you can request a file-based store for a service’s SEDA queue as follows:

<service name="serviceExplicitObjectStore">    ...    <queue-profile>        <file-queue-store/>    </queue-profile></service>

You can also explicitly configure a custom object store to use for a service’s SEDA queues by specifying the <custom-queue-store> child element in the <queue-profile> element, as shown in the following example:

<service name="serviceCustomObjectStore">    ...    <queue-profile>        <custom-queue-store class="..."/>    </queue-profile></service>

And you can specify a queue store for a flow, that is, if the flow uses the queued-asynchronous processing strategy. You specify the queue store in an appropriate child element in the global processing strategy for the flow. Here’s an example:

<queued-asynchronous-processing-strategy name="customStoreQueueStrategy">    <file-queue-store/></queued-asynchronous-processing-strategy><flow name="asynchronousFlow" processingStrategy="customStoreQueueStrategy">  <vm:inbound-endpoint path="input" exchange-pattern="one-way"/>  <vm:outbound-endpoint path="output" exchange-pattern="one-way"/></flow>