Giving answers for following questions:
Is data updated only in TimesTen (TimesTen masters the data) or only in Oracle (Oracle masters the data, TiemsTen data is query only)? Ans: Data will get updated in only oracle.
Is the same data present at each location or is the data set at each location disjoint (nothing in common with other locations)? Ans: same data present at each location
If data is updateable in TimesTen, do you need updates made at one location to be visible in other locations or just at location where they were made and Oracle? Ans: Data will not be updateable in TimesTen. Data will get updated in only oracle. All TimesTen instance should get synchronized automatically.
What kind of network connectivity (round trip latency, bandwidth, reliability) exists between the locations and the central Oracle DB? Between the different locations? Ans: There will be dedicated line for network connectivity(as per bandwidth requirement)
Do you need any kind of HA? If so, what are the details? Ans: No.
On the basis of what you have described it sounds like you will want READONLY cache groups in a TimesTen database deployed at each of the 6 sites. These cache groups will use the AUTOREFRESH feature to capture data changes made in the Oracle database and to synchronise them up to the TimesTen caches.
Applications running at the 6 sites can connect to the TT caches to query cached data. To access/update Oracle data there are two options:
1. The applications can perform this through the TimesTen connection using the PassThrough featire. This may be a good choice if the amount of direct application interaction with Oracle is low and not performance critical.
2. The applications maintain a separate connection directly to Oracle and use this for all access to Oracle tables. This is the bets choice if there will be heavy interaction directly with Oracle and/or these interactions are performance critical.
You will need to ensure that:
1. The latency and bandwidth of the connections from the 6 sites to the Oracle DB are sufficient to cope with all traffic (direct application access to Oracle, autorefresh for cache groups data).
2. You will need to consider the volume/rate of changes that are made to tables in oracle which are cached in TimesTen to ensure you are not exceedign the capabilities of the AUTOREFRESH mechanism.
I suspect that you will need to do some kind of PoC to validate these various aspects.
The architecture you propose is a good one because:
1. It has the TimesTen database/cache that is being refreshed from Oracle located at the same siet as Oracle (and hence on the same LAN, not over a WAN).
2. Having just one autorefresh stream in Oracle maximises performance and minimises resource usage.
For this architecture to work you need to make one change. The TimesTen deployment at the main Oracle DB site must be a replicated pair of TT caches (using TimesTen active/standby pair replication) not a single TT cache. The remote sites will then be 'subscribers' driven from the central A/S pair. You should consider using Oracle CLusterware to manage the central A/S pair as it will be much simpler than writing your own scripts etc.