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 |
|
|
The numer of elements that may be stored in the defined cache |
Result
The result is returned in the OUT body as an ArrayList<HashMap<String, Object>>
. The List
object contains the list of rows and the Map
objects contain each row with the String
key as the column name.
Note: This component fetches ResultSetMetaData
to be able to return the column name as the key in the Map
.
Message Headers
Header |
Description |
---|---|
|
If the query is a |
|
If the query is an |
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");