Cache Component
The cache component enables you to perform caching operations using EHCache as the Cache Implementation. The cache itself is created on demand or if a cache of that name already exists then it is simply utilized with its original settings.
The Cache component has the following abilities
a> In Producer mode, the component provides the ability to direct payloads in exchanges to a stored in a pre-existing or created-on-demand Cache. The producer mode supports operations to ADD/UPDATE/DELETE/DELETEALL elements in a cache. (Examples given below)
b> In Consumer mode, the component provides the ability to listen on a pre-existing or created-on-demand Cache using an event Listener and receive automatic notifications when any cache activity take place (i.e ADD/UPDATE/DELETE/DELETEALL). Upon such an activity taking place, an exchange containing header elements describing the operation and cachekey and a body containing the just added/updated payload is placed and sent. In case of a DELETEALL operation the body of the exchanage is not populated.
c> There are a set of nice processors to the camel-cache component to provide the ability to perform cache lookups and selectively replace payload content at the
- body
- token
- xpath level
The Cache consumer is an event based consumer and can be used to listen and respond to specific cache activities. If you need to perform selections from a pre-existing cache, used the processors defined for the cache component.
URI format
cache:cacheName[?options]
This component supports producer and event based consumer endpoints.
You can append query options to the URI in the following format, ?option=value&option=value&...
Options
Name |
Default Value |
Description |
---|---|---|
|
|
The numer of elements that may be stored in the defined cache |
|
|
The number of elements that may be stored in the defined cache. Options include
|
|
|
Specifies whether cache may overflow to disk |
|
|
Sets whether elements are eternal. If eternal, timeouts are ignored and the |
|
|
The maximum time between creation time and when an element expires. |
|
|
The maximum amount of time between accesses before an element expires |
|
|
Whether the disk store persists between restarts of the Virtual Machine. |
|
|
The number of seconds between runs of the disk expiry thread. The default value |
Sending/Receiving Messages to/from the cache
Sending data to the cache involves setting the Message Exchange Headers given in the section below.
Message Headers
Header |
Description |
---|---|
|
The operation to be performed on the cache. The valid options are
|
|
The cache key used to store the Message in the cache. The cache key is optional if the CACHE_OPERATION is DELETEALL |
Cache Producer Samples
In the following example, we fetch the rows from the customer table.
First we register our datasource in the Camel registry as testdb
:
Then we configure a route that routes to the JDBC component, so the SQL will be executed. Note how we refer to the testdb
datasource that was bound in the previous step:
Or you can create a DataSource
in Spring like this:
We create an endpoint, add the SQL query to the body of the IN message, and then send the exchange. The result of the query is returned in the OUT body:
Sample - Polling the database every minute
If we want to poll a database using the JDBC component, we need to combine it with a polling scheduler such as the Timer or Quartz etc. In the following example, we retrieve data from the database every 60 seconds:
from("timer://foo?period=60000").setBody(constant("select * from customer")).to("jdbc:testdb").to("activemq:queue:customers");