All,
I just wanted to quickly add my 2 cents worth on JCS and its maturity.....
1) I have been using JCS for single node caches for a few months and have
had no issues really to speak of. The LRUMemoryCache without memory
shrinking, with size limits, and using both eternal and timeout objects...
to be more precise.
2) I initially implemented our multi-node caching system using the default
JCS implementation of TCP-based lateral caching, but a few things kept us
from going to production with it as is:
- The need for cached objects to be Serializable (actually an issue for us
for the basic CacheElements in general)
- I wanted the lateral cache to do nothing more than send notifications to
other nodes when an element, or a cache should be invalidated.
- When using more than 2 nodes, the connection recovery mechanism did not
properly reconnect all the nodes together when they were finally all
available.
3) I have gone ahead and modified JCS for our system, and resolved the three
issues from 2). I know I saw some old discussions regarding Serializable
objects only, allowed in the Caches and couldn't find a definitive decision,
but my existing implementation works fine for us. Without opening a can of
old worms, I would be interested in finding out the concensus on this.
4) My implementation of the LateralTCPCache works pretty well now. I added
a NotifyMode property, that when true will make the Lateral Cache never try
to send a Cached object over the wire. I think there is value in this kind
of remote cache clustering...any comments.
Thanks for the work that has gone into JCS so far. I have not done all the
reading necessary to figure out what it takes to contribute code to the
project, so I haven't posted any of these changes...is it worthwhile for me
to do this?
Thanks,
Joe
-----Original Message-----
From: James Taylor [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, December 04, 2002 6:56 PM
To: Turbine JCS Users List
Cc: '[EMAIL PROTECTED]'; Blair Harrison; Tatum Lade;
Lee Parayno
Subject: Re: Hibernate and JCS Questions
> 1) How mature is JCS? Who is using it? On how many machines? With which of
> the three major configurations (fully distributed, client/server,
> client/cluster)?
I am using it. Two machines, memory caches on each. Put only lateral
distribution between them with javagroups. Quite basic really.
Others? (I'm curious too)
> 2) What was the process by which Gavin gained sufficient confidence in JCS
> to include it in Hibernate?
>
> 3) Why does Gavin indicate that JCS can't be used in a clustered
read-write
> environment, in contradiction to the JCS documentation?
I suspect the biggest problem is that there is no distributed locking,
for JCS, which makes it difficult to use for O/R mapping. In my case, we
cache immutable read mostly data objects, and when the underlying data
store is updated for an entity, it is purged from the cache.
For more mutable data, I do not cache.
> 4) If we were able to commit to using Hibernate in a read-only fashion and
> doing our data writing some other way, changing the data out from under
> Hibernate, which various legacy admin tools will do anyway, does this
change
> the preference profile between Hibernate's session-level cache vs. JCS? If
> so, how?
>
> The bottom line, quite frankly, is that we're nervous about relying on JCS
> in the absence of some reassurances about its maturity and use in the real
> world, as JCS is clearly attempting to solve difficult engineering issues,
I wouldn't call JCS mature, but it works reasonably well for some
peoples needs, and is a good place to start for a distributed cache. But
because it has no consistency guarantee between nodes in the cache, I'm
not sure it is workable for O/R mapping and multiple nodes.
(However, I believe one could implement an auxilliary which provided
more consistency -- all the hooks should be there)
--
To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
