tons of tools and documentation about how to make RMI stubs for your JDK version. You can even make your own custom collection for doing this, similar to …
This document assumes you already have a basic working understanding of
JCS, and you wish to now make your caches ˜Remote to other caches
Some terminology specific to this document:
Remote Cache Server or just server: A dedicated instance of JCS which
accepts incoming connections from outside JCS Caches
Remote Cache Client or just client: A JCS Cache usually running within
another application which uses the Remote Cache Server as an auxiliary
cache
First of all, a brief discussion of what ˜Remote Cache means:
A Remote Cache Server is a JCS cache which provides a listening socket for
other JCS caches to talk to A JCS cache the client is then configured to
talk to the server, and the client treats the server as an auxiliary cache
When the client has a cache miss, it synchronously asks the remote cache if
it has that object, and if the server does, the client will cache it
locally, and return a cache hit with that object
When the client does a put, it asynchronously puts that object on the
server, who in turn tells all other clients to remove their copy
When the client does a remove, it asynchronously tells the server to remove
that object, who in turn tells all other clients to
remove their copy
Step by step instructions this assumes youve already built JCS:
1 Build the RMI stubs for:
orgapachejcsauxiliaryremoteRemoteCacheListener
orgapachejcsauxiliaryremoteRemoteCacheWatchRepairable
orgapachejcsauxiliaryremoteZombieRemoteCacheService
orgapachejcsauxiliaryremoteZombieRemoteCacheWatch
orgapachejcsauxiliaryremoteserverRemoteCacheServer
orgapachejcsauxiliaryremoteserverRemoteCacheServerListener
Theres tons of tools and documentation about how to make RMI stubs for
your JDK version If youre using a jar that already has them, more power
to you If youre getting messages about not having something ending in
_Stub, go back to this step
2 Deploy a stand-alone instance of JCS to be the Remote Cache Server
Make a new cacheccf and rename it to remotecacheccf Youll want to have
the following line in your remotecacheccf:
registryhost127001 or your IP here
registryport1099 or whatever port you want it to listen on
All the normal cacheccf settings apply here, so you can configure your
remote cache just like you would any other cache
3 Start the Remote Cache Server
At the command line:
java
orgapachejcsauxiliaryremoteserverRemoteCacheServerFactory path
to remotecacheccf/remotecacheccf
Be sure to specify your classpath, and include all the jars in the lib
directory in it
If you get a message about permission denied while trying to read the
remotecacheccf, yet all your filesystem permissions are ok, youll need
to modify your JAVA_HOME/jre/lib/security/javapolicy to allow permissions
to that file To grant all permissions for everything DANGEROUS you can
add the following to the bottom of your javapolicy
// Warning This is a dangerous and bad thing to do
grant {
permission javasecurityAllPermission;
};
Its expected that youll decide what policy is best for your
configuration, and wont just grant permission to everything which is what
those 3 lines above do
If you receive messages about not knowing what IP or host to use, you may
need to specify the following argument at the command line when starting
java:
-Djavarmiserverhostnameyour server IP here
The local IP can be found automatically on a nix system with the following
script:
if [ -z LOCALIP ]
then
LOCALIFeth1
LOCALIP/sbin/ifconfig LOCALIF | grep inet | cut -d : -f 2 | cut -d \
-f 1
Fi
Be sure and change
LOCALIF to the interface you want
If you see a message about not being able to bind to the port, make sure
you dont already have another instance running, and that nothing else is
using that port
If you see nothing at all, theres a good chance the Remote Cache Server is
up and working no news is good news
4 Configure the client to talk to the server
In your cacheccf on the client, define a new auxiliary cache:
jcsauxiliaryRCorgapachejcsauxiliaryremoteRemoteCacheFactory
jcsauxiliaryRCattributesorgapachejcsauxiliaryremoteRemoteCacheAttri
butes
jcsauxiliaryRCattributesFailoverServersserver IP:server port
jcsauxiliaryRCattributesRemoveUponRemotePutfalse
jcsauxiliaryRCattributesGetOnlyfalse
In this instance were calling it RC, but youre free to call it whatever
you want, and make multiple instances which point at different servers, and
have different regions point at these different instances
Now add the remote cache either to your default region:
jcsdefaultDC,RC
Or to your specific regions:
jcsregioncomspecific regionDC,RC
The disk cache as an aux cache as shown in the lines above is, of course,
optional
5 Try it out
Easiest way to try it is to do a put on the client, wait a
second, shut it
down and start it back up, then try and do a get If the get returns your
object, Remote Cache is working
Caveats:
Doing a put to remote will not do a put to all other clients Instead the
server asks the other clients to remove the object The next time a client
asks for it, it will get a local cache miss, and ask the remote for it
Remote Cache has no consistency guarantees Put and Remove events to remote
cache happen asynchronously
Gotchas:
Putting objects in cache, and collections of those same objects or objects
with references to those same objects in cache will result in duplicate
objects in memory when using remote cache
Take the following example:
You load up a series of objects from a database, and put them in cache,
keying each by its PK
You then make a collection of these objects, and stick said collection in
the cache
So far, so good Both JCS and the Collection/Composite both point at the
same objects, so your references look like this:
Now we bring remote cache into the picture We put the objects up into
Remote Cache They get serialized, and constructed anew on the remote
server:
Heres where the problem starts You now put the
collection up on Remote
Cache The entities get serialized again, and created anew again on the
remote side:
When another client requests the objects, and the collection, the problem
will be duplicated on that side If you dont pay attention to the fact
that on certain boxes the objects your modifying via the collection arent
the objects youll get from cache, but on other boxes they will be, you can
run into some very strange behavior
Suggestions for avoiding this:
Make your collections/composites reference the PKs of the objects instead,
and look them up via your persistence/caching framework when retrieving
from the collection You can even make your own custom collection for doing
this, similar to Hibernates Lazy Loading collection
———————–
Entity1
Entity2
JCS
Collection or Composite Object
Entity1
Entity2
JCS
Collection or Composite Object
JCS
Entity2
Entity1
Entity1 dupe
Entity2
dupe
