Child pages
  • DSO Data Structures Guide
Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 113 Next »

About Terracotta Documentation

This documentation is about Terracotta DSO, an advanced distributed-computing technology aimed at meeting special clustering requirements.

Terracotta products without the overhead and complexity of DSO meet the needs of almost all use cases and clustering requirements. To learn how to migrate from Terracotta DSO to standard Terracotta products, see Migrating From Terracotta DSO. To find documentation on non-DSO (standard) Terracotta products, see Terracotta Documentation. Terracotta release information, such as release notes and platform compatibility, is found in Product Information.

Unknown macro: {div9}
Release: 3.6
Publish Date: November, 2011

Documentation Archive »

Clustered Data Structure Guide

Introduction

This guide is intended to provide you with the information you need to make informed decisions about which data structures to use in which context, how to maximize their efficiency, and how to avoid certain pitfalls.

Clustered data structures in Terracotta are functionally equivalent to their non-clustered counterparts. However, there are some performance differences between the different data structures in a clustered context that are important to understand when designing a system. Some of the performance differences are inherent to the design of the data structure; for example, the very different synchronization and concurrency characteristics of Hashtable, HashMap, and ConcurrentHashMap. Other performance differences come from the implementation of a data structure that is expected to work in a local context but operates somewhat differently in a clustered context. Still other differences are simply the result of point-in-time implementation details in the Terracotta core engine. Be sure to check this document regularly to see the status of these point-in-time effects.

Unknown macro: {HTMLcomment}
  1. Coming Soon

    1. A discussion of cross-JVM latency and concurrency patterns.
  2. Latency

  3. TODO: describe the effect of cross-JVM latency and how to plan for it – what is "cross-JVM" latency
  4. Concurrency

  5. TODO: describe the effect of different concurrency patterns and how to plan for them.

Important Concepts for Concurrent Data Structures

A number of important concepts relating to concurrent data structures are discussed in this document. These concepts are defined in the following sections.

Partial Loading

A data structure that can be partially loaded can have portions of itself loaded into a client JVM, while other portions remain unloaded until accessed. Partial loading, which is sometimes referred to as "lazy loading," happens on Terracotta clients, not Terracotta server instances.

Logically Managed Objects

One of the main motivations for partial loading comes from the need to efficiently handle logically managed objects. Most of the data structures in the java.util and java.util.concurrent packages that are supported by Terracotta are logically managed, which means they are kept up-to-date across JVMs by replaying the method calls made in another JVM. This is done for performance reasons and, in the case of hash-based structures, for correctness. However, because they aren't managed by keeping track of their physical references to other objects, they do not share the same virtual heap mechanism enjoyed by physically managed objects. (For more information on physically and logically managed objects, see the Concept and Architecture Guide)

Without special support in the Terracotta core, logically managed data structures are loaded in their entirety into a client JVM when they are accessed. In the case of very large data structures, this can lead to a number of application issues:

  • The data structure may take a long time to load from the Terracotta server.
  • The data structure may take up too much space in the local JVM heap.
  • The data structure may exceed the available JVM heap, leading to OutOfMemoryErrors.

To solve these problems, Terracotta implemented partial loading for some data structures. In the case of certain Map implementations, the entire key set is loaded when the Map is loaded, but the values are not. The values are loaded automatically when the value is accessed. This can have a significant improvement on heap usage for clustered Maps.

Literals and Partial Loading

A data structure with values that are all literals (a set which includes Java primitives) is not partially loaded. Only the portion of a data structure with object references for values can be partially loaded. For a data structure with mixed values — both literals and object references — the literals are all loaded while the non-literals are partially loaded. For example, a map with only large numerical or String values is fully loaded. For more information on literals in Terracotta, see the Concept and Architecture Guide.

Keys and Partial Loading

In data structures with key-value pairs, keys are never partially loaded. Collections with extremely large key sets or extremely large keys may still have a significant impact on a JVM's memory. Key values should be kept to the smallest size that still serves the application. Key sets that become too large are an indication that the data should be further partitioned.

Specific Data Structures and Partial Loading

Because the partial loading algorithm for each data structure is different, not all data structures are partially loaded. The implication is that data structures that are partially loaded have different implementation and performance characteristics under different scenarios. For a list of data structures that can be partially loaded, see [Data Structure Characteristics Table].

Synchronization

Synchronization refers to standard Java synchronization, which makes a data structure thread-safe by introducing locking. Without synchronization, data cannot be guaranteed to be correct. Internal synchronization is a necessary characteristic for a data structure to get Terracotta cluster-wide locking, or auto-locking.

Auto-Locking

Auto-locking refers to the locking available on synchronized data structures where Terracotta promotes the local lock to a cluster-wide lock. In Terracotta, auto-locking can be automatic on certain data structures, or configured on other data structures. This guide shows which data structures are automatically auto-locked by Terracotta.

Concurrency

Concurrency, a crucial and integral part of Java, is the ability to perform simultaneous operations on the same data. Data structures have concurrency if they can safely allow concurrency. Terracotta automatically extends the concurrency of certain data structures across JVMs in a cluster.

Latency

Latency is the lag of response to some requested action. In a data structure, latency is the time taken to complete an action on the data. Latency in data structures varies depending on the data-access characteristics of your application.

Locality of Reference

High locality of reference typically implies low latency because required data is available in local memory. Locality of reference is Low if the fault rate for data is high.

Data Structure Characteristics Table

The following table shows how a number of the concepts discussed in [Important Concepts for Concurrent Data Structures] are applied to certain data structures. If a data structure name in the Data Structure column is a link, you can click it to go to a section with more information on that data structure.

Unknown macro: {table-plus}

Data Structure

Terracotta Partial Loading

Java Concurrent

Java Synchronized

Terracotta Autolocking

[array]

Unknown macro: {center}

Unknown macro: {center}

NO

Unknown macro: {center}

NO

Unknown macro: {center}

NO

ArrayList

Unknown macro: {center}

*

Unknown macro: {center}

NO

Unknown macro: {center}

NO

Unknown macro: {center}

NO

AtomicInteger

Unknown macro: {center}

N/A

Unknown macro: {center}

YES

Unknown macro: {center}

YES

Unknown macro: {center}

NO

AtomicLong

Unknown macro: {center}

N/A

Unknown macro: {center}

YES

Unknown macro: {center}

YES

Unknown macro: {center}

NO

[ConcurrentHashMap]

Unknown macro: {center}

Unknown macro: {center}

YES

Unknown macro: {center}

YES

Unknown macro: {center}

HashMap

Unknown macro: {center}

Unknown macro: {center}

NO

Unknown macro: {center}

NO

Unknown macro: {center}

NO

HashSet

Unknown macro: {center}

*

Unknown macro: {center}

NO

Unknown macro: {center}

NO

Unknown macro: {center}

NO

[Hashtable]

Unknown macro: {center}

Unknown macro: {center}

NO

Unknown macro: {center}

YES

Unknown macro: {center}

TIM

[LinkedBlockingQueue]

Unknown macro: {center}

Unknown macro: {center}

NO

Unknown macro: {center}

YES

Unknown macro: {center}

LinkedHashMap

Unknown macro: {center}

Unknown macro: {center}

NO

Unknown macro: {center}

NO

Unknown macro: {center}

NO

LinkedList

Unknown macro: {center}

*

Unknown macro: {center}

NO

Unknown macro: {center}

NO

Unknown macro: {center}

NO

[POJO]

Unknown macro: {center}

Unknown macro: {center}

NO

Unknown macro: {center}

NO

Unknown macro: {center}

*

TreeMap

Unknown macro: {center}

2.8

Unknown macro: {center}

NO

Unknown macro: {center}

NO

Unknown macro: {center}

NO

TreeSet

Unknown macro: {center}

*

Unknown macro: {center}

NO

Unknown macro: {center}

NO

Unknown macro: {center}

NO

[Vector]

Unknown macro: {center}

*

Unknown macro: {center}

NO

Unknown macro: {center}

YES

Unknown macro: {center}

TIM

– The characteristic is a Terracotta feature automatically available with this data structure.
YES – The characteristic is part of this data structure.
TIM – The characteristic is not part of this data structure, but can be added by using the appropriate Terracotta Integration Module (TIM).
NO – The characteristic is not part of or is not automatically available for this data structure.
* – The characteristic is not part of this data structure at this time, but may become so.
Version number – Support for this characteristic begins with the indicated Terracotta version number.
N/A – Not Applicable.

Selected Data Structures

Additional information is available on the following data types.

Arrays

Unlike many other data structures, Java arrays cannot contain mixed types. Arrays contain either literals or object references. An array containing literals will not be partially loaded, while an array containing object references will be partially loaded.

ConcurrentHashMap

Unknown macro: {table}
Unknown macro: {tr}
Unknown macro: {td}

Package

Unknown macro: {td}

java.util.concurrent

Unknown macro: {tr}
Unknown macro: {td}

Type

Unknown macro: {td}

Map

Unknown macro: {tr}
Unknown macro: {td}

Available with Java Version

Unknown macro: {td}

1.5

Unknown macro: {tr}
Unknown macro: {td}

Latency Characteristics

Unknown macro: {td}

Slow on full iterations because all segments must be loaded and traversed. Low-latency if accessing narrow set of values; higher latency if accessing wide set of values.

Unknown macro: {tr}
Unknown macro: {td}

Special Characteristics

Unknown macro: {td}

Read access is fully concurrent. Write access is exclusive of read and write access per segment.

ConcurrentHashMap (CHM), unlike a synchronized wrapper around a java.util.HashMap, has very good concurrency characteristics that are exploited by Terracotta in a clustered context.

  • Unlike synchronized collections which are locked using a monolithic mutex for all operations, CHM uses read and write locks.
  • CHM keys are partitioned into separate segments so when exclusive access is required, when for example two threads need to write to the same segment, only the segment is locked instead of the entire data structure.
  • Terracotta clustered CHMs have full read concurrency such that all read operations are allowed to occur concurrently.
  • Terracotta clustered CHMs have a read locking optimization such that all read lock acquisitions become greedy concurrently on all relevant nodes. This allows read lock acquisition to happen without a network hop to the Terracotta server on every node. For more information on the greedy lock optimization in Terracotta, see the Concept and Architecture Guide.
  • Read operations do not have to wait for write operations on other partitions to fully complete.
  • While the key set is monolithically loaded, the values are partially loaded.

Hashtable

Unknown macro: {table}
Unknown macro: {tr}
Unknown macro: {td}

Package

Unknown macro: {td}

java.util

Unknown macro: {tr}
Unknown macro: {td}

Type

Unknown macro: {td}

Map

Unknown macro: {tr}
Unknown macro: {td}

Available with Java Version

Unknown macro: {td}

1.0

Unknown macro: {tr}
Unknown macro: {td}

Latency Characteristics

Unknown macro: {td}
Unknown macro: {tr}
Unknown macro: {td}

Special Characteristics

Unknown macro: {td}

You can install a TIM called tim-collections to add auto-locking to Hashtable. To learn more about TIMs, see the following resources:

LinkedBlockingQueue

Unknown macro: {table}
Unknown macro: {tr}
Unknown macro: {td}

Package

Unknown macro: {td}

java.util.concurrent

Unknown macro: {tr}
Unknown macro: {td}

Type

Unknown macro: {td}

queue

Unknown macro: {tr}
Unknown macro: {td}

Available with Java Version

Unknown macro: {td}

1.5

Unknown macro: {tr}
Unknown macro: {td}

Latency Characteristics

Unknown macro: {td}
Unknown macro: {tr}
Unknown macro: {td}

Special Characteristics

Unknown macro: {td}

This queue is partially loaded, synchronized, and autolocked by Terracotta, making it a good choice for shared data that must be in a producer-consumer queue. An important difference between LinkedBlockingQueue and other partially loaded data structures is that items in LinkedBlockingQueue are not cleared once loaded into the JVM.

POJOs

While a POJO is not explicitly a collection, Terracotta will partially load a POJO's object-reference fields. If your code is designed to use POJOs to store, share, and manipulate data, your application can benefit from partial loading. The more your application's POJOs are optimized for partial loading, the greater the benefit.

Literal fields are loaded all at once. See [Partial Loading] for more information.

Vector

Unknown macro: {table}
Unknown macro: {tr}
Unknown macro: {td}

Package

Unknown macro: {td}

java.util

Unknown macro: {tr}
Unknown macro: {td}

Type

Unknown macro: {td}

List

Unknown macro: {tr}
Unknown macro: {td}

Available with Java Version

Unknown macro: {td}

1.0

Unknown macro: {tr}
Unknown macro: {td}

Latency Characteristics

Unknown macro: {td}
Unknown macro: {tr}
Unknown macro: {td}

Special Characteristics

Unknown macro: {td}

You can install a TIM called tim-collections to add auto-locking to Vector. To learn more about TIMs, see the following resources:

  • No labels