JGrinderX - Is ObjectWave's new generation persistence and distributed data caching framework. JGrinderX evolves from JGrinder and it integrates with GemFire Enterprise Data Fabric to enable distributed data caching. Click here to see an online demo of JGrinderX Framework in action. Visit our all new JGrinderX site.

About JGrinder

JGrinder is an Object to Relational mapping solution for providing Java persistence.
Databases supported: File, Access, Hypersonic, Oracle, MySQL.
Highlights:

• Designed from objects point of view.
• Simplicity
• Keeps object deltas
• Fast
• http://jgrinder.sourceforge.net/

About GemFire

• GemFire is a high-performance, distributed operational data management infrastructure.
• GemFire sits between clustered application processes and back-end data sources to provide very low-latency, predictable, high-throughput data sharing and event distribution.
• GemFire enables extremely high-speed data sharing that turns a network of machines into a single logical data management unit - a data fabric.

JGrinderX/GemFire Integration Background

Typical Application Architecture

• Business Txs processed by Business Objects within the Application Server
• JGrinder maps objects to relational DB
• DB is used to store passive data for long term store.
• Data is passive and requires to be loaded every time is needed.
• Bottleneck: The Application Server - As application load (Tx volume) increases, performance degrades at the App Server level.
  

Solving App Server Bottleneck

• - Application Servers are added to handle more load.
• - Some load balancing strategy is introduced.
• - JGrinder maps objects to relational DB
• - DB is used to store passive data for long term store.
• - Data is still passive and requires to be loaded every time is needed.
• - Bottleneck: The Database - As application load (Tx volume) increases, performance  degrades at the DB level.

Solving Database Bottleneck:

• - A Local Cache is added to each Application Servers to minimize DB access.
• - Cache is initialized at application startup, and is limited to static data rarely updated.
• - JGrinder maps objects to relational DB
• - DB is used to store passive data for long term store.
• - Data is still passive and requires to be loaded every time is needed.
• - Bottleneck: Slow application startup process due to cache synchronization process. Impacts DB during startup.

Solving Cache Synchronization Bottleneck:

• - A Distributed Cache is added to connect the local cache for each Application Server.
• - Various distributed cache topologies can be implemented to obtain maximum performance and availability.
• - App. Server can quickly recover from a crash from local cache persistent store.
• - Distributed Cache technologies harness the memory and disk resources across a network minimizing the need to access the DB.
• - Data becomes more active, all data required by the application is now in memory drastically improving overall application performance.
• - DB is now used to store passive data as backup or for archiving and data warehousing.
• - Bottleneck: Network.

Why Integrate JGrinderX with GemFire

• Provide Distributed Cache Functionality to enable distributed data sharing
• Introducing a Distributed Cache, requires the introduction a new data access API into the application code.
• Applications have to be aware of where they need to get the data from for processing.
• If not cached they need to get it from the DB and then put it into the cache.
• JGrinder’s original intention was to hide the data access. A Distributed Cache from JGrinder’s point of view is just another data store.
• Applications will only have to deal with JGrinder API.
• JGrinder can handle the cache and db access.