Terracotta DB is a distributed in-memory data management solution for both operational storage and analytical processing. Terracotta DB has powerful query and computation capabilities, leveraging native JDK features such as Java Streams, collections, and functions. It supports the following sub-systems:
A storage sub-system fronted by TCStore API
A caching sub-system fronted by the next generation Ehcache API which includes and extends JSR 107
Both sub-systems are backed by the distributed Terracotta Server, which provides a common platform for distributed in-memory data storage with scale-out, scale-up and high availability features.
Terracotta DB 10.3 release introduces key enterprise readiness features and analytical capabilities in Terracotta DB. With this release, Terracotta DB took a big leap forward to support multi cloud deployments, security, and operational usability. Some of the notable features of Terracotta DB 10.3 include:
- Azure certification as a supported platform for Terracotta DB deployments.
- Terracotta DB is now available on docker store.
- Security enhancements including Authentication, Authorization and Auditing.
- Support for local transactions in Terracotta DB through Transaction API extension.
- Write-behind support for clustered Ehcache.
- Hybrid storage support.
- Configuration helpers for simple to use XML based configuration import and export.
- Numerous operational usability enhancements including latency metering, refactoring and role based access in Terracotta Management Console.
Support for Terracotta DB Websessions (Clustered Session Management component for Terracotta DB) is included with release. (10.3.0.3)
Summary of Changes 10.3.0.3
- 4249 – Fixed bug related to sending dataset description during replication and cleanup
- 4149 – Implemented a more efficient backoff waiting algorithm for IO during secure handshake in order to remove a performance degradation when secure network communications are enabled.
Summary of Changes 10.3.0.2
- 4098 – The external voter now tracks server partition events and takes care not to vote for multiple servers in the same partition event.
- 3989 – Resolved client not reconnecting to newly promoted active after failover. This happened when cluster was configured for consistency mode with external voters.
- 3912 – Resolved an “IllegalStateException: Tx slot starvation!” occurring in TCStore for read-heavy loads. User will most likely encounter this when the server has a limited number of processors available and many RecordStreams are processed. (The number of concurrent reads was limited to 16 times the number of processors.) The correction for this removes that limit for read loads without concurrent updates.
Summary of Changes 10.3.0.1
- 3122 - Fixed error to correctly depict handshake error when server is not reachable(due to partition) and TCStore attempts to reconnect
- 3591 - Fixed the display of server status in SPM plugin from ‘UNKNOWN’ to ‘NOT READY’ when server is syncing, stuck or suspended.
- 3732 - Added enhancement to emit configuration to log after cluster tool reconfiguration
- 3805 - Resolved issue to make cluster-tool.bat, bcrypt.bat or start-tc-voter.bat executable on windows
- 3829 - Resolved issue when secured server would be allowed to start in case keys in certificates are not generated with RSA algorithm.
- 3834 - Enabled secure connections for Voter
- 3841 - Added warning for users for mismatched port/hosts
- 3873 - Enhanced Cluster tool server-level status command to provide more details during failures
- 3875 - TMC now shows security status for connection between TMS and the cluster
- 3879 - TMS Server at the startup should migrate the tmc.properties from older version by introducing the newly added properties in 10.3 with default values and update the renamed properties
- 3882 - TMC resource panel now displays server status
- 1699 - Ehcache EE now automatically registers its management registry if absent
- Terracotta BigMemory 4.x and Terracotta DB 10.x clients may be used simultaneously in the same application by ensuring ClassLoader isolation when initializing at least one of the clients.
- Beginning with 10.3, users should move to the new 10.3 security properties (tms.security.root.directory, tms.security.https.enabled and tms.security.root.directory.connection.default).