Oracle TimesTen In-Memory Database

Oracle had produced forth a bunch of In-Memory processing, where part of the In-Memory architecture consisted of In-Memory relational databases called TimesTen.

Some notes from Oracle on TimesTen In-Memory DB:

TimesTen is commonly deployed with multi-user and multi-threaded applications using row-level locking and read-committed isolation. Applications access TimesTen databases using standard SQL via JDBC, ODBC, ODP.NET, OCI (Oracle Call Interface), Pro*C/C++, and Oracle PL/SQL programming interfaces. While the best response time is achieved with TimesTen running in-process with the application (also known as "direct mode"), conventional client/server access is commonly used when a database is shared by several applications running on different servers.
TimesTen databases are persistent and recoverable. Durability is achieved through a combination of transaction logging and database checkpointing to disk.
High Availability is provided using TimesTen Replication to replicate transactions between TimesTen databases in real-time. Due to the mission-critical nature of TimesTen applications, most enterprise deployments add TimesTen Replication for availability and disaster recovery. For example, telecommunications and web-accessible global systems such as online-charging, subscriber session management, eCommerce online stores, travel and reservation websites cannot tolerate application/service downtime; financial services and securities trading systems must remain continuously available while financial markets are open.

TimesTen Replication uses memory-optimized, transaction log-based replication technology over a network efficient and stream-based protocol for high performance, reliability, and robustness. Key features include:

• Asynchronous replication, providing maximum performance, and completely decoupling the application from the subscriber receipt process of replicated elements;
• Synchronous replication, providing a higher level of confidence for data consistency between the active and standby databases; the application is blocked until the replicated transaction has been both received and committed on the standby database;
• Hot read availability of the standby database; additional read capacity can be provided by configuring additional read-only subscribers;
• Parallel replication for applications that require very high transaction throughput;
• Automated failure detection and failover to the standby database, achieved by seamless integration with Oracle Clusterware;
• Online upgrades, allowing individual servers to be taken offline for software upgrades, while other servers continue uninterrupted.

For applications with existing data already residing in an Oracle database, caching a performance-critical subset of the data into the TimesTen in-memory database is a practical solution to improve application transaction response time. Refer to the TimesTen Application-Tier Database Cache Overview here.