Gigaspaces implementation of Castor JDO Cache.
Gigaspaces supports a wide variety of cache topologies, allowing the user
to distribute and/or replicate application data as needed. This cache instance
replicates this flexibility by allowing you to configure it (and thus the
underlying Gigaspaces instance) as follows.
<cache-type type="gigaspaces">
<cacheUrl>/./</cacheURL>
<cacheProperties>schema=cache</cacheProperties>
</cache-type>
As mentioned briefly above, the main issue is the cache topology usage. Per
definition, Gigaspaces caches can be started in various modes:
- Embedded - cache running as part of the application VM
(/./myCache?schema=cache)
- Remote - means you need to run cache server and have relevant
url at the client to connect to it (jini//*/*/myCache)
- Master local - means you need to run a cache server and have relevant
url at the client to connect to it. The URL should include
'useLocalCache' as part of it
(jini//*/*/myCache?useLocalCache)
Each of the above can run in
replicated or
partitioned mode. This
means you should run several instance in one of the above mode using the relevant
schema name, total_membres and id.
instance 1:
"
/./myCache?schema=cache&cluster_schema=replicated&total_members=2&id=1"
instance 2:
"
/./myCache?schema=cache&cluster_schema=replicated&total_members=2&id=2"
or
instance 1:
"
/./myCache?schema=cache&cluster_schema=partitioned&total_members=2&id=1"
instance 2:
"
/./myCache?schema=cache&cluster_schema=partitioned&total_members=2&id=2"
When running the cache in server or in embedded mode, you
must have the
cache schema to be used, i.e. '
schema=cache'.
For more information on cache topoligies and the use of URLs with Gigaspaces,
please see
here.
For more details on Gigaspaces in general, please see http://www.gigaspaces.com/.