We have a lot of active deployments where people need to integrate Terracotta into a use case where the goal is to offload the database. Transactional updates between Terracotta, working as a cache, and the database would seemingly slow the cache updates down to the speed of the database. This line of reasoning is not only common but quite logical. However, it's not true at all. There are two ways that using Terracotta as a cache in front of the database can offload that database, and offload it significantly. The first mechanism for offloading the database and the most common is using Terracotta in write-behind mode. The second is to use Terracotta as a coherent read cache writing through to the database. In both cases, the database can either be made smaller or can handle many more transactions per unit time.
When writing behind to the database, Terracotta's integration module for asynchronous updates, (Async TIM) provides a simple, scalable pure Java way to offloading I/O. The Async TIM provides an API for flagging objects in any collection as "dirty" and needing update to any backing store. The module guarantees that objects dirtied by a particular JVM do not migrate across JVMs in the process of getting flushed to the DB. This means that each JVM is working with only the changes it makes--all in a highly localized fashion. The Async TIM thus provides a mechanism for flushing data that changes from application JVMs back to the database; a way to flush those changes at a rate the database can support, keeping data in the Terracotta array until it reaches the db; and a way to make sure the entire system is reentrant and that no data or events will be lost or duplicated between the cache and the database, even in the case of an entire cluster restart. Async TIM's work queues are all Java queues running on top of Terracotta so the queues are durable, transactional data backed transparently by the Terracotta server array. A large online gaming site and a social networking customer both use Async TIM to write fast changing information directly to the cache. The online gaming site writes odds and game data, as well as all bets being placed by end users into the DB for eventual settlement / payment. The social networking site writes highly contented inventory information to a central cache of product availability. Both have decreased their database from an Oracle instance running on Sun hardware from >12 CPUs down to 4, which means a really nice savings in Oracle licenses.
When writing through to the database, Terracotta's configuration-based locking semantics layered on top of a pure Java collections prove sufficient for our customers in offloading excessive I/O. Start with a simple HashMap. Execute all reads from the cache and all writes straight to the database. In order to execute a transactional update with the DB, use a Terracotta synchronous lock to flag the cache as stale, cluster-wide. Then the database write is done in a normal, fast Terracotta asynchronous lock (using just Java synchronization but flagging the object locks as asynchronous at runtime), finishing with reflagging the cache as clean. We at Terracotta call this a 1.5 phase commit. Whenever reading from cache, we are guaranteed that the database is the master of all data and that the cache is subservient because the cache will not be valid until set clean, and it cannot be clean unless the database and cache got updated without error. A major telco uses Terracotta collections with a 1.5 phase commit locking scheme in order to offload their database, increasing the capacity of their existing cluster by 7.5X. At time when you want to do more with less, that's a good return.
As you can see, Terracotta helps both asynchronous write-behind users and synchronous write-through users offload the DB quite significantly. In one case, customers use durable, transactional POJO queues to write to the DB in a throttled manner. In the other, customers use coherent cluster-wide read caching and a 1.5 phase locking scheme to all but eliminate read traffic to the database.