Checkpoints

Non-Blocking Blocking Fuzzy

TimesTen maintains two checkpoint files (ds0 and ds1) on disk to keep track of metadata of in-memory permanent data. It switches two files when a checkpoint is done to ensure there is always at least one completed checkpoint file for backup and recovery purpose. The rate for checkpointing disk writes is configurable by application. It supports fuzzy or non-blocking checkpoints as well as transaction-consistent checkpoints (i.e. blocking checkpoints).

Compression

Dictionary Encoding

TimesTen supports columnar compression. This feature uses dictionary-based encoding to replace column values with dictionary table identifiers. It maintains separate dictionary for each column.

Concurrency Control

Multi-version Concurrency Control (MVCC) Two-Phase Locking (Deadlock Detection)

Concurrency control of TimesTen is achieved through isolation and locking. It supports fully ACID transactions but allow user to loose it for performance by modifying configuration.

Locking

TimesTen provides three level of lock granularity: row-level, table-level and database-level. By default, row-level locking is used to maximize the throughput.

Deadlock Detection

Deadlock detection is supported in TimesTen with a subdaemon process checking every 2 seconds. It reports and eliminates deadlock when the situation occurs. Application should roll back and retry entire transaction when it is denied a lock due to deadlock error.

Data Model

Relational

TimesTen implements actual relational data model instead of just a relational view.

Foreign Keys

Supported

TimesTen supports foreign keys with proper constraints according to relational database model. Each table may have one or more foreign keys to reference columns in other tables. Foreign key feature is performed through range indexes. Specific constraints implemented in TimesTen for foreign key can be read in documentation of FOREIGN KEY.

Indexes

B+Tree Hash Table BitMap T-Tree

TimesTen originally used T-Tree indexes as default. Later version of TimesTen moved to range indexes (B+Tree) and supports also hash and bitmap indexes if explicitly specified.

Isolation Levels

Read Committed Serializable

TimesTen provides two different levels of transactional isolation: read committed and serializable. Read committed isolation is used by default. Application can use attribute to change isolation level for its connections and different levels are allowed for concurrent connections.

Read committed isolation

Read committed isolation level enables lockless reads (locks still needed during view maintainence) by reading a separate committed copy of data while writes performed on its own uncommited copy (multi-versioning). In this case, write only blocks other writes. If transaction in this level is performed with operations in serializable isolation level, reads are still non-blocking but write operations block both reads and writes in serializable isolation mode. This mode provides better concurrency comparing to serializable isolation but with the consequences of non-repeatable reads.

Serializable isolation level

This level is used with database-level lock. All locks acquired are kept until the transactions commit or abort.

Joins

Nested Loop Join Sort-Merge Join

TimesTen provides two different join method for the optimizer: nested loop join and merge join. Merge join is chosen only when join occurs on columns sorted by range indexes.

Query Compilation

Code Generation

TimesTen compile a SQL query through four stages: parser, semantic analyzer, optimizer and eventually code generator to produce executable code.

Query Interface

SQL

TimesTen implements industry-standard SQL interfaces.

Storage Architecture

In-Memory

TimesTen has data resides in main memory. It still stores checkpoint files and transaction log files on disk to achieve persistency.

Stored Procedures

Supported

TimesTen allows creating standalone stored procedures as well as provides some built-in procedures.

System Architecture

Shared-Nothing Shared-Everything

TimesTen Scaleout uses a shared nothing architecture to achieve linear scalability. Management and administration are centralized and operated on management instances while actual tasks are executed on separate data instances.

Views

Virtual Views Materialized Views

TimesTen supports both view (a.k.a non-materialized view) and materialized view. The difference between the two leads to different calculation costs. For view, the cost is paid by the connection that queries the view. While for materialized view, the connection which updates the detail tables encounter the costs.

View

A view is logical and contains no data and therefore will not be dropped or altered by calling those commands on detail tables. If those operations are performed on detail tables with a view presented, referencing the view may fail.

Materialized view

Materialized view is read-only and not available with cache tables. There are two types of materialized view according to update mechanisms: synchronous and asynchronous.