<< Multi Node Distributed Caching - TOC - Cache from multiple Data Sources >>
In this section, different cache modes have been discussed. Applications can use any of the modes as per their requirements.
In the below examples the table ‘t1’ is cached which is present in MySQL , Postgres or Oracle database.
The records present in the table t1 are:
SQL>SELECT * FROM t1; +------+-------------+ | f1 | f2 | +------+-------------+ | 1 | Hello World | | 2 | Hi | | 3 | Hi | | 4 | No One | | 5 | EveryOne | +------+-------------+
In this mode, application can perform all DML operations on the cached table. Updates on the cached tables are automatically applied in the target database. This is the default-caching mode in CSQL.
There are two types of partial caching,
Record Level Cache: Use –c option to specify the condition for partial caching. Records, which satisfy the condition, will be cached in CSQL from the target database.
$cachetable -U root -P manager -t t1 -c "f1 < 3"
CSQL>select * from t1;
-----------------------------------
f1 f2
-----------------------------------
1 Hello World
2 Hi
Column Level Cache: Use –f option for specifying the field name list to retrieve only values of those fields from the original table
$cachetable -U root -P manager -t t1 -f "f1"
CSQL>select * from t1;
-------------------------------------
f1
--------------------------------------
1
2
2
3
4
5
It caches only record values for ‘f1’ field in table ‘t1’ from the target database.
In this cache mode, updates to cache directly go to the target database table and will not update the cached table. This mode is useful when there is auto increment field in cached table. Use –D option to cache table in this mode
$cachetable -t T1 -D
CSQL>select * from T1;
-------------------------------
f1 f2
--------------------------------
1 Hello World
2 All
3 Hello
Insert one record in cache table and query the table
$csql -g
CSQL> insert into T1 values ( 4, 'Hi');
$cachetable -t T1 -D
CSQL>select * from T1;
-------------------------------
f1 f2
--------------------------------
1 Hello World
2 All
3 Hello
Though one more record is inserted, it is not inserted in cache table; rather, the record is inserted in target database. Check it in MySQL.
This mode is useful in cases where scalar functions or auto increment key is used during DML operations. In such cases, bi-directional cache mode should be turned on so that updates directly goes to target database and comes back to cache eventually within cache receiver wait seconds maintaining the data consistency between cache and target database.
An asynchronous cache mode enforces the same caching behavior as Synchronous cache mode, in which cached data is updated in CSQL and propagated to target database. This mode is also called write behind cache. This mode provides better response times than Synchronous because the CSQL commit occurs asynchronously for the target database commit. This allows an application to continue executing without having to wait for the target database transaction to commit. The updates can be performed on cached tables in Async mode even when the target database is down. When the target database restarts, the updates will be applied to the target database automatically.
A Synchronous cache enforces a caching behavior in which cached data in CSQL as well as original table in target database is updated before execution returns. Synchronous mode gives high cache consistency and is suited for real time applications. When target database goes down, transactions fail till the target database restarts. This is the default mode for propagating updates to target database. 12.6. Unidirectional Cache The default caching in CSQL is unidirectional caching, which means all updates (INSERT, UPDATE, DELETE) on cached tables will be automatically propagated to target database.
CSQL supports bi-directional caching in which, direct updates on target database are propagated to CSQL cache automatically.
<< Multi Node Distributed Caching - TOC - Cache from multiple Data Sources >>