Building High Scalability Apps With Terracotta


Published on

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.

Published in: Technology
  • Terracotta is supported on linux. As far as .NET goes, you could take a look at the Ehcache Cache Server APIs. It provides RESTful and SOAP web service interfaces to a standalone ehcache server.
    Are you sure you want to  Yes  No
    Your message goes here
  • Well presented!
    But I'm looking for a solution that is supported in .NET and the one solution that I know is NCache. Is terracotta supported in .NET and on Linux platform?
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Building High Scalability Apps With Terracotta

  1. 1. Building High Scalability Apps with Terracotta David Reines Senior Architect Object Partners Inc. twitter: dhreines
  2. 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. 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. 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. 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. 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
  7. 7. Terracotta Cluster
  8. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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
  18. 18. Designing to Scale * Transparent Failover
  19. 19. Demo
  20. 20. References
  21. 21. Data Structures (via