Contact Free trial Login

Object Store Connector

An Object Store is a Mule component that allows for simple key-value storage. Although it can serve a wide variety of use cases, it is mainly design for:

  • Storing synchronization information, such as watermarks.

  • Storing temporal information such as access tokens.

  • Storing user information.

Additionally, Mule Runtime uses Object Stores to support some of its own components, for example:

  • The Cache module uses an Object Store to maintain all of the cached data.

  • The OAuth module (and every OAuth enabled connector) uses Object Stores to store the access and refresh tokens.

  • The <until-successful/> component uses an Object Store to store all the messages it has to retry. So, if Mule crashes, those messages are not lost and can continue processing when it recovers.

Object Store Limitations

Object Stores are not a universal solution for data storage. They do not replace a database, and they are not suitable for every use case. Most importantly, they do not support transactional access or modification. For use cases in which ACID semantics are needed, or for cases where you expect the same key to be updated in parallel, consider another solution.

Using the Default Object Store

By default, each Mule app has an Object Store that is persistent and always available to the app without any configuration. Flows can use it to persist and share data.

If you want to use the default Object Store, you can specify a key for the Object Store without selecting or creating an Object Store reference for the Object Store operation, and without specifying an objectStore attribute in the XML element for the Object Store component.

Note that the Mule app is deployed into CloudHub workers through Anypoint Platform Runtime Manager, the contents of the Mule app’s default Object Store are visible in Runtime Manager, within the Mule app’s Application Data tab.

It is important to understand that the only Object Store displayed in the Runtime Manager Application Data tab is the default Object Store.

Using a Custom Object Store

Custom Object Stores must specify an objectStore attribute. These Object Stores can be configured to behave differently than the default Object Store. For example, you can indicate whether the Object Store is persistent (so that the Object Store data survives a Mule Runtime crash) or transient (where data does not survive a Mule Runtime crash). Here are some common reasons for defining custom Object Stores:

  • You want to partition your information by storing it in different Object Stores.

  • You want to use advanced Object Store features such as these:

    • Transient/Persistent storage.

    • Specification of a time to live (TTL).

    • Specification of a max capacity.

  • You want to keep different components from sharing state by feeding them with different Object Stores.

  • You want different components to share information by feeding them with the same Object Stores.

We use cookies to make interactions with our websites and services easy and meaningful, to better understand how they are used and to tailor advertising. You can read more and make your cookie choices here. By continuing to use this site you are giving us your consent to do this.