JBoss World Boston notes, Using Infinispan for high availability, extreme performance, Manik Surtani & Galder Zamarreño
Infinispan as…
in memory object cache
… clustering/high availability toolkit
… clustered in-memory cache
… in-memory data grid
… cloud ready data store
Local, in-memory object cache
– performance booster
– good when data is hard to calculate, expensive to retrieve or frequently accessed
Better than hashmap
– better concurrency
– built-in eviction
– overflow to disk
– warm start, preloading
– events, notifications
– highly configurable locking strategies
– JTA compatible
– JMX monitoring
Tips and tricks
– use eviction, low-cost boudnedd container, recency based: LIRS
– tune for read-heavy, use lock-striping, READ_COMMITTED is often sufficient
– pre-loading can be expensive
Clustering toolkit
– High availability
– fail-over
– scale-out
– uses self-discovery, self-healing
Tips and tricks
– strive for session affinity, very valid optimization, will allow fo async communication
– replicated mode vs distribution? Depend on cluster size
– distribution: co-locate related state
– pre-loading, state transfer not necessary, use a ClusterCacheLoader
Clustered in-memory cache
– performance booster
– similar to local cache
– cluster-aware
– more shared-cache space
Writing data in cache, use putForeExternalRead() vs put()
– update cache state vs update “real” state
– fail-fast instead of lock
– fail quietly instead of throw exception
– does not affect transaction
Tips and tricks
– same as local cache
– putForExternalRead() API
– use invalidation clustered mode
— very efficient: only keys on the wire
— async communication helps even more
– replication can be used
— if cluster is small and data cached is small
— overall data volume can be contained in a single node
In-memory data grid
– multiple access mechanisms
– embedded: P2P
– client/server: REST, memcached, HotRod
– familiar APIs
— cache API
— upcoming JPA-like API
– Queryability
FADE: Fast, Available, Distributed, Elactic
Tips and tricks
– session affinity is nice to have
– async communication and eventual consistency
– use distributed mode, replicated will work to a limit
– tune performance vs durability, numOwners
– dedicated data tier helps you build stateless, elastic application tier
– HotRod: most efficient endpoint
Cloud-ready data store
– RDBMS in inelastic, single point of failure
– data grid deals with transience, is elastic, scalable, distributed
– API is key
Tips and tricks
– asme as data grids
– REST: use load balancer
– use a transport that does not use multicast (not supported on something like EC2)