RE: a few things -- RE: cvs commit: jakarta-turbine-stratum/src/ java/org/apache/stratum/jcs/engine/control/group GroupAttrName.java

[Aaron Smuts <AS...@therealm.com>]

If the key ends with the configurable character (which is a colon by
default) then it is treated as a partial removal.  It should be in the
remove methods of the memory cache and the disk cache.

I think non String keys will be ignored.  If you want to use string keys
then you can use this hierarchical / partial removal.  It is extremely
useful.  I think I mentioned it in some of the documentation.



> -----Original Message-----
> From: John McNally [mailto:jmcnally@collab.net]
> Sent: Friday, March 29, 2002 3:14 AM
> To: Turbine Developers List
> Subject: Re: a few things -- RE: cvs commit: jakarta-turbine-
> stratum/src/java/org/apache/stratum/jcs/engine/control/group
> GroupAttrName.java
> 
> Aaron Smuts wrote:
> ...
> > A few comments:
> >
> > >   Log:
> > >   fixed several places that were assuming keys were Strings, they can
> be
> > >   any Serializable object.
> >
> > This may not (or should not?) be the case.  There is a hierarchy
> > functionality that may assume that the keys are strings.  The keys are
> > checked to see if they end with the wild card ":".  We could add a
> special
> > remove method that forced string keys?
> >
> > I started forcing the string values for a reason.  I can't remember the
> > status of this.
> >
> 
> I started using a special purpose object as the key when using jcs
> within torque.  I did not get any casting exceptions, though I am only
> using the memory cache, so I have not tested the full functionality.
> Can you point to where the hierarchy is implemented?  What happens if
> the key contains colons that are not meant as separators?
> 
> > I see little value in non string keys.  We can get much more
> functionality
> > with string keys.  The partial removal is extremely powerful.  It allows
> you
> > to avoid the overhead of groups and clean up quickly.  It cannot be
> > sacrificed.
> 
> You use the value of general keys in creating GroupAttrName and
> GroupId.  And I am using it in torque.  I would like to see the wildcard
> implementation.  But looping over all the keys parsing each one to look
> for a partial string does not sound efficient.
> 
> >
> > Any thought on the value of non String keys?
> 
> 
> I have a List that I would like to cache.  The objects that are in the
> list depend on a set of other objects.  So I make the set of objects the
> key.  Not sure how I can use a String to accomplish this easily and I
> cannot force the positions of colons.  I guess I could make sure to
> remove any colons from any strings that are generated.  What is the
> overhead of groups that makes all this work attractive?
> 
> >
> > >
> > >   fixed one place that assumed the group name was an Object.  It is
> > > currently
> > >   always a String.
> > >
> > >   made CacheException extend commons NestedException.  This gave a
> > > classpath
> > >   issue in RMI, that I do not fully understand, but giving the
> commons-
> > > lang jar
> > >   as a classpath attribute allows the build to work.
> > >
> > >   fixed a few places where jcs was ignoring exceptions with no
> explanation
> > > as to
> > >   why.  There are quite a few more.
> > >
> >
> > Early on, following JCache, I started throwing exceptions for common
> > scenarios like the object was not found or already existed.  This made
> it
> > cumbersome to use and followed a model of excessive exception throwing
> that
> > I find distasteful, so I removed them.  In the process I commented out a
> few
> > IOExceptions that maybe I shouldn't have.  I'm not sure that an
> exception
> > will ever get pushed up that high though.
> >
> > I'd like for the user to only have to import the root package.  They
> should
> > be able to use the JCS access class.  Maybe a root or abstract
> JCSException
> > class should be put in the same folder to make it easier to use.  There
> is
> > nothing worse then having to figure out a million imports to use third
> party
> > software.
> >
> 
> I was assuming CacheException would be the main/general exception thrown
> by jcs.  I'm all for moving it to the top level.  For that matter I
> think the interfaces should be top level with implementations pushed
> further down.
> 
> john mcnally
> 
> --
> To unsubscribe, e-mail:   <mailto:turbine-dev-
> unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:turbine-dev-
> help@jakarta.apache.org>

RE: a few things -- RE: cvs commit: jakarta-turbine-stratum/src/ java/org/apache/stratum/jcs/engine/control/group GroupAttrName.java

[James Taylor <jt...@4lane.com>]

> I think non String keys will be ignored.  If you want to use string keys
> then you can use this hierarchical / partial removal.  It is extremely
> useful.  I think I mentioned it in some of the documentation.

If they are not ignored they can be =]

> > I have a List that I would like to cache.  The objects that are in the
> > list depend on a set of other objects.  So I make the set of objects the
> > key.  Not sure how I can use a String to accomplish this easily and I
> > cannot force the positions of colons.  I guess I could make sure to
> > remove any colons from any strings that are generated.  What is the
> > overhead of groups that makes all this work attractive?

My understanding of the partial removals is that the colons don't matter
until you actually try to do a partial removal, so as long as you don't
use them colons are not a problem. Aaron?

> > I was assuming CacheException would be the main/general exception thrown
> > by jcs.  I'm all for moving it to the top level.  For that matter I
> > think the interfaces should be top level with implementations pushed
> > further down.

I agree. I think the interfaces are a little intimidating. Pushing the
key interfaces down where they are useful, and removing them where they
are not, would make JCS much easier to understand. 

Aaron, do you have any thoughts on merging the regular and group caches?
Specifically what might the performance implications of such a move be?

Thanks,
James


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>