This content has been marked as final. Show 5 replies
1. TimesTen is designed to be a embedded cacheable database for best performance and stores all the data in memory,
will my application run into out of memory error if data is very large?For large data what's the best options for jvm?
CJ>> A TimesTen database is shared memory segment so it does not directly use memory from the JVM. However, if your application runs on the same machine as TimesTen and connects in 'direct' mode (recommended) then the shared memory segment has to be mapped into the JVM address space. This means that the JVM process has to have a large enough, free, contiguous address range for that mapping to occur. If you have a lot of data (1GB+) this means that; (a) your machine has to have enough physical RAM to support the JVM, the Java application, the TimesTen datastore (all the data you wish to store in TimesTen) and any other requirements, (b) you should use a 64-bit machine with a 64-bit O/S, 64-bit TimesTen and 64-bit JVM.
2. TimesTen replica is capable of failure tolerance, does this mean my application that embeds TimesTen will failover operations to the active node if local node is crashed?
I really want to know is it transparent to my application or I need process this situation?
CJ>> No, in general it is not transparent. If you are connecting to TimesTen in client/server mode (much slower than direct mode) there is a degree of transparency (not 100%) but for direct mode the application or something external to the application must handle the 'application failover'. We strongly recommend that you use Oracle Clusterware (Grid Infrastructure) to manage A TimesTen HA pair and Clusterware has functionality to help with application failover.
3. If two independent TimesTen instaces connect to the same oracle database,opertions on one TimesTen instance will be consistent with the other?
CJ>> The answer is 'it depends'. It depends on (a) the kind of caching you are using and (b) how the application uses the data. For READONLY caching the answer is essentially 'yes' but for updateable caching then there are additional considerations.
Addition to Chris's written.
2. TimesTen replica is capable of failure tolerance, does this mean my application that embeds TimesTen will failover operations to the active node if local node is crashed? I really want to know is it transparent to my application or I need process this situation?
CJ>> No, in general it is not transparent. If you are connecting to TimesTen in client/server mode (much slower than direct mode) there is a degree of transparency (not 100%) but for direct mode the application or something external to the application must handle the 'application failover'.Basically it is not transparent, but if you use the client/server connection to timesten you can use the TAF technology (similar to RAC TAF technology). More information in documentation (http://docs.oracle.com/cd/E21901_01/doc/timesten.1122/e21638/writing_app.htm#BABDIJGC) and an example (http://ggsig.blogspot.co.uk/2010/11/taf-oracle-timesten.html, sorry for Russian).
In fact I want to set up two independent TimesTen instances that connect to the same oracle instance as 2 updateable cache layers.
I think this approach could avoids failover or complexity of TimesTen HA.
My two applications can talk with its independent TimesTen instance directly.
So will update operations, saying updating a row , in one TimesTen instance be visible to the other?
If not for HA have I to set up the TimesTen cluster(replica) instead,
I really not want to introduce more unknown stuff such as Oracle Clusterware (Grid Infrastructure).
With A/S pair replication (HA) the standby is read only. You cannot directly write to any replicated table in the standby.
With two independent updateable cacche groups, up[dates made in oen will propagate to Oracle but will *not* be propagated to the other cache group (that's what independent means in this context). The best architecture here is to partition the data and workload so cache group 1 handles half the data (A-M say) and the other handles the rest (N-Z). That way there is no need to have the updates propagate to the other TT database. The alternative, if your workload is suitable, would be to us Cache Grid but that is onyl suitable for certain use cases and absolutely needs both HA and Clusterware for any real world deployment.