Overview

See the architecture usage example below:

This architecture diagram demonstrates usage of GigaSpaces and its database caching for parallel database query. This architecture is based on the classic master-worker pattern as defined in the procedure below:

1. J2EE session bean submits tasks to GigaSpaces.
2. The tasks contain the required information for workers to process and generate the relevant query.
3. Task submission occurs via JavaSpaces Write API.
4. When there are many tasks to submit, use the writeMultiple API to accelerate the task submission process.
5. Workers using the JavaSpaces Take API pick up the tasks.
6. Workers can run in the GigaSpaces container or the J2EE container (as session beans or threads started from Servlets). The number of workers can be static or dynamic. If dynamic, new workers can be added, as needed, based on system load.
7. Workers can run on one or more machines to provide an unlimited scalability level.
8. Workers generate the query and submit it to the database via object to relational Hibernate API.
9. The object to relational API uses the GigaSpaces Distributed Cache to accelerate the query processing and supply the query result from the local/remote cache if it was already loaded.
10. Cached data can be retrieved either from the local cache, embedded within the worker, or from the master remote cache. The local cache is limited in memory size and evicts data automatically. The worker reads cached data first from the local cache; if the data is not found, the worker obtains it from the master cache. GigaSpaces performs this action automatically .
11. Each worker sends the query result back into the J2EE session bean via the JavaSpaces Write method.
12. The J2EE Session bean that submitted the tasks now uses Take API to obtain all results. When they all arrive, it sends the total result back to the client.
13. The space used for the tasks/results submission and for the remote master cache is fully clustered to provide both scalability and availability.