Senior Architect David Reines will present the simple yet powerful clustering capabilities of Terracotta. David will include a brief overview of the product, an in-depth discussion of Terracotta Distributed Shared Objects, and a live load test demonstrating the importance of a well designed clustered application.
David Reines is a Senior Consultant at Object Partners Inc. He has lead the development efforts of several mission-critical enterprise applications in the Twin Cities area. During this time, he has worked very closely with numerous commercial and open source JEE technologies. David has always favored a pragmatic approach to selecting enterprise application technologies and is currently focusing on building highly-concurrent distributed applications using Terracotta.
Automating Google Workspace (GWS) & more with Apps Script
Building High Scalability Apps With Terracotta
1. Building High Scalability Apps
with Terracotta
David Reines
Senior Architect
Object Partners Inc.
david.reines@objectpartners.com
twitter: dhreines
2. Agenda
Terracotta Overview
Products
Distributed Shared Objects (DSO)
Architecture
Distributed Shared Objects
Roots and Instrumented Classes
Locks
Data Structures
Object Identity
Designing to Scale
Demo
3. Terracotta Overview
Terracotta is an open source software solution that provides JVM-level
clustering.
Plugs into the Java Memory Model
Utilizes bytecode manipulation
Consistent
Creates a virtual heap across multiple nodes
Provides highly optimized cluster-wide locking
Available
Terracotta active/standby servers provide high-availability
Data persisted to disk to survive certain disaster scenarios
Terracotta Server Array provides "linear" scalability
4. Terracotta Products
Terracotta Products
Distributed Ehcache
cache eviction algorithms
write-through/write-behind
JTA support (XA compliant)
monitoring
Distributed Ehcache for Hibernate
Job Store for Quartz
Web Session Clustering
Spring Framework Clustering
Distributed Shared Objects
the foundation of Terracotta Products
5. Terracotta Architecture
Client JVM(s) (L1)
Application logic
Communicates with active Terracotta server(s)
Supports numerous standard containers
Utilize Terracotta Integration Modules (TIMs)
Terracotta Server(s) (L2)
Data management
data storage (memory and disk)
full-fill L1 data requests/change broadcasts
distributed garbage collection
Lock management
Active server(s) replicate data to standby server(s) in real-
time
6. Deployment Options
Permanent Storage
Recommended for high-availability mode
Stores data to disk (Berkeley-DB)
Disk speed will impact performance
Active/Standby
Allows for high availability
Active server "elected" at start-up
Automatic failover if active fails
Terracotta Server Array (Enterprise Only)
Provides "linear" scalability
Multiple active/standby "mirror groups"
Transparent to the application tier
8. Open Source vs. Enterprise
Open Source Version
Production ready
High availability
Very high throughput and performance
Developer console
Limited to a single active server
Enterprise Version
Terracotta Server Array (Terracotta FX)
Additional Enterprise Operations and Management Tools
Production back-up and restore
Certified Patches, Support
Simple upgrade from open source to enterprise version.
9. Distributed Shared Objects (DSO)
As a developer, you may never need to work directly with
Terracotta DSOs.
Terracotta products such as Ehcache hide the complexity of
DSOs from developers.
The concepts are still important because DSOs provide the
foundation for Terracotta's products.
If needed, developers can still utilize DSOs directly.
10. Root
Root
Applications define root(s)
A root and it's references are clustered
A root cannot be changed
/**
* Singleton CustomerService.
*/
private class CustomerService {
@Root
private ConcurrentDistributedMap<Long, Customer>
customers;
}
11. Instrumented Classes
Instrumented Class
Shared objects must be instrumented
Serializable not required
Root container is automatically instrumented
/**
* Shared Customer.
*/
@InstrumentedClass
public class Customer {
...
}
12. Locks
Terracotta Locks
Provide cluster-wide synchronization
Provide a means for terracotta "transactions"
Modifications to clustered objects must occur within a
clustered lock.
Utilizes standard Java synchronization syntax
Lock Support
read/write
synchronous-write
ReentrantReadWriteLock
Lock Optimization
Greedy locks - once obtained, no need to contact server
13. Object Identity
Objects are assigned a cluster-wide ObjectId
Object identity is maintained cluster-wide!
Multiple objects can reference the same object instance cluster-
wide
Only data changes are broadcast
Not completely true when using ehcache serialization mode.
Good reasons for either option. Ehcache provides the flexibility
to choose per cache.
14. Designing to Scale
Partial Loading and Locality of Reference
To properly scale an application can utilize partial
loading to maintain a good locality of reference .
15. Partial Loading
Consider the following example:
Map<String, ReallyBigObject>
Loading all elements into each node limits scalability.
Partial Loading a Map
Terracotta faults the keys into each node in the cluster
Values are faulted into node(s) as needed
Data Structures Supporting Partial Loading
DSO Data Structures Guide
(i.e. LinkedBlockingQueue)
16. Locality of Reference
Always access and update the same data on the same node.
For example, CustomerId 100 is always accessed on Client JVM #1
Benefits
Uses partial loading
Minimizes lock recalls - greedy locks
Minimizes fault rates
Minimizes flush rates
Minimizes change broadcasts
Reduces L1 garbage collection cycles
17. Locality of Reference (cont)
Potential Routing Options
Load-balancers (i.e. session, url or header properties)
Custom Client Libraries
Potential Routing Keys
HttpSession Id
CustomerId
UserId
etc...
Failover
If a node fails, route requests to another server
Objects transparently fault into memory
