Please recommend solutions for Cache Connect and ?

Question

---> Solution I
2 servers create Cache Connect to RDBMS
---> Solution II
1 server create Cache Connect to RDBMS and create active standby pair with another server

Answer 1

Hi,
If you only need READONLY caching in TimesTen and all updates will be made in Oracle then you have two main options:
Multiple READONLY Caches
For this you have one or more separate TimesTen caches each with a READONLY cache group defined against the oracle DBMS. Each cache can cache different tables/data or they can can cache the same tables/data as required.
This architecture is very flexible (adding or removing TimesTen servers is very simple) and very scalable. It also provides very good HA; if one cache is down applications can just access a different cache.
However, due to the asynchronous, time based nature of the refresh from Oracle to Timesten at any moment in times the data in all the caches may not be 100% consistent with each other or Oracle.
By this I mean the following:
- Assume that you have 2 (or more) READONLY caches caching the same data from Oracle, with an AUTOREFRESH interval of T1
- At some time, T2, you update, in Oracle, one of the rows cached by the caches.
- At some later time, T3, you query the updated row via both caches
If (T3 - T2) < T1 then the values returned by your query may differ between the caches (depending on where exactly they are in the autorefresh interval when the update is done).
Active/Standby pair using 2-SAFE replication with READONLY cache group and optional read-only subscribers
With this architecture you define a TimesTen Active/Standby replicated pair using 2-safe replication and containing the READONLY cache group. 'Scale out' is accomplished in one of three ways:
1. Adding further A/S pairs with a READONLY cache group
2. Adding read-only subscriber datastores to the original A/S pair
3. A mixture of (1) and (2)
The main advantages of this architecture are as follows:
1. When 2-Safe is used within the A/S pair, queries to either cache will always return consistent results (i.e. the consistency issue that I described for the first scenario does not exist in this configuration). However, threr can still be inconsitencies in results between the A/S pair and any readonly subscribers (since the replication to them is asynchronous) but given the high performance of TimesTen replication the latency between a change appearing at the A/S pair and the readonly subscribers will typically be a few ms rather than potentially several seconds for the multiple-cache scenario.
2. The loading on the central Oracle DBMS arising from AuTOREFRESH processing is reduced compared to the multiple-cache scenario. The difference in loading between this solution and the multiple cache solution will be larger as more TT servers are deployed.
It should be noted that the operational management of this solution is a little more complex than for the first scenario since the A/S pair must be monitored and a 'failover' trigerred if there is some fauilure within the pair.
Hope that helps a little.
Chris