THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
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:
Error formatting macro: snippet: java.lang.NullPointerException
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:
Error formatting macro: snippet: java.lang.NullPointerException
Or you can create a DataSource in Spring like this:
Error formatting macro: snippet: java.lang.NullPointerException
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:
Error formatting macro: snippet: java.lang.NullPointerException
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");