struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Antony Joseph" <ajosep...@lycos.com>
Subject Re: Caching Appliction Level Data?
Date Mon, 14 Feb 2005 21:27:39 GMT
You may want to look at Oscache. It allows clustering. That is what I use in my applications.
Even though I use iBATIS,  for list of values which change infrequently, I use oscache with
with a spring AOP interceptor invalidating the cache whenever updates/inserts happen. Because
I am using spring, when the data layer is accessed a transaction gets started (even though
no db acces may occur because the data is found by iBATIS in cache) and is something I wanted
to avoid because these values are used so often. Also I believe whenever a cache is configured
with iBATIS the method calls within iBATIS are synchronized.

If you want to see how the read through cache is implemented using oscache, check out the
Workeffort application at http://www.logicden.com

I just released it under Apache license. Take a look at the file OsCacheController.java, LovInterceptor.java
and InvalidateLovInterceptor.java

----- Original Message -----
From: "Soaring Eagle" <comfortable.numb@gmail.com>
To: "Struts Users Mailing List" <user@struts.apache.org>
Subject: Re: Caching Appliction Level Data?
Date: Mon, 14 Feb 2005 15:54:54 -0500

> 
> how do you manage cross container caches if you are clustered - when
> you are using static members on classes? How do guarantee sameness on
> different physical machines? We do have a few caches in our
> application and are facing issues due to this design or an improperly
> implemented version of this design.
> 
> Thanks.
> 
> 
> On Mon, 14 Feb 2005 15:01:21 -0500 (EST), Frank W. Zammetti
> <fzlists@omnytex.com> wrote:
> > On Mon, February 14, 2005 2:53 pm, David Johnson said:
> > > I think I get it. Static classes I get, but I guess I didnt consider
> > > that any static member of a static class is always accessible. It
> > > still strains my brain a little, actually, but I guess it makes sense.
> >
> > Yeah, static is one of those things that people tend to get confused about
> > early on.  Don't worry, time will make it rather clear and you'll
> > eventually wonder how there was ever a time it didn't make sense :)
> >
> > > so you'd recommend this above creating some hashtable and just
> > > plunking it in Application scope then. What are the advantages of this
> > > way over the "sticking it in app scope" method?
> >
> > Hmm... Honestly, I never thought much about benefits over anything else :)
> > Thinking about it NOW though, the only one that comes to mind is that
> > "sticking is in app scope" is tieing you to a servlet environment.  Think
> > of it this way... ideally, each part of your application should be
> > testable on it's own, even OUTSIDE Tomcat or whatever servlet container
> > your using (I think you said Tomcat and maybe Weblogic eventually?)
> >
> > If you just have a static class, it's a POJO (Plain Old Java Object),
> > which means you can test it to your hearts' content without Tomcat.
> >
> > Not this the class I posted would need much testing :)  But still.
> >
> > > My only issue is that the application already has a few things hanging
> > > off the ServletContext as attributes, and it would seem inconsistent
> > > for maintenance I suppose..
> >
> > That's a fair point, especially to someone like me who tends to be overly
> > anal about consistency :)  I would argue that you may not want whatever
> > you have hanging off ServletContext to be there either, for the same
> > reason as above.  If you know your app would never need a different
> > presentation then it's not really a concern, but building flexibility into
> > a design at all levels makes life easier later when the inevitable scope
> > creep comes out to bite you :)
> >
> > Frank
> >
> > > ----Separate thing-----
> > > what about the problem where some of the stuff I'd need in my listener
> > > is actually being set up in a struts plug-in (that's the way it is
> > > currently)
> > >
> > >
> > > On Mon, 14 Feb 2005 14:34:23 -0500 (EST), Frank W. Zammetti
> > > <fzlists@omnytex.com> wrote:
> > >> On Mon, February 14, 2005 2:26 pm, David Johnson said:
> > >> > Frank
> > >> >
> > >> > I see what you mean. I was assuming I'd just store the data in a
> > >> > hashtable or something in the Application Context
> > >>
> > >> That's what I think Wendy suggested, and it's probably a better idea
> > >> than
> > >> what I do frankly :)
> > >>
> > >> > I have stupid question...where is your AppConfig actually getting
> > >> > stored? I'd think you'd need to do the above at some point and do
a
> > >>
> > >> No question is stupid :)
> > >>
> > >> > getServletContext().setAttribute( AppConfig, "myAppInfo");
> > >> >
> > >> > oh boy what am I missing.. or was that implied.. OR did I miss your
> > >> > hwhole point? I really hope it's not the last one ;)
> > >>
> > >> Your forgetting some basic Java is all (and everyone does it from time
> > >> to
> > >> time, regardless of what anyone might claim :)
> > >>
> > >> A member of a class that is static is always present in the CLASS,
> > >> independent of any instance of that class.  For instance:
> > >>
> > >> public class myClass {
> > >>  public static int PI = 3.14159;
> > >> }
> > >>
> > >> Now, if you have another class that wants to use PI, you just do:
> > >>
> > >> public class test {
> > >>  public void showPI() {
> > >>    System.out.println(myClass.PI);
> > >>  }
> > >> }
> > >>
> > >> No instance of myClass is created, yet you can access the PI member of
> > >> it
> > >> through the instance of the CLASS... That's sometimes confusing to
> > >> people... The way I learned to think of it is that the JVM (the class
> > >> loader specifically) in a sense does automatically creates an instance
> > >> of
> > >> the myClass class, but an instance that ONLY contains the static
> > >> members.
> > >> That's not actually what happens AFAIK, but IN EFFECT it is.
> > >>
> > >> As long as the two classes are loader by the same class loader, your
> > >> good
> > >> to go.
> > >>
> > >> > For this app it's safe to assume we'll always be using struts (btw)
> > >>
> > >> Then a plugin is safe.  But, as others have said, it's just about as
> > >> easy
> > >> to do it other ways, so you may as well have one less Struts tie-in.
> > >> And
> > >> as Vic I think said, DAOs are the best-practice (one I haven't had cause
> > >> to use yet myself, but I in *no way* disagree with his point).
> > >>
> > >> --
> > >> Frank W. Zammetti
> > >> Founder and Chief Software Architect
> > >> Omnytex Technologies
> > >> http://www.omnytex.com
> > >>
> > >> >
> > >> > On Mon, 14 Feb 2005 14:15:28 -0500 (EST), Frank W. Zammetti
> > >> > <fzlists@omnytex.com> wrote:
> > >> >> Using a plugin only tells you WHERE your going to read the
> > >> information
> > >> >> in,
> > >> >> not where your going to STORE it.  I think that's the question
you
> > >> >> really
> > >> >> want to ask.  Plugins are pretty standard practice when dealing
with
> > >> >> Struts, but if you have a concern that you might not be using
Struts
> > >> at
> > >> >> some point, you might want to do something else.
> > >> >>
> > >> >> In any case, where you put the data is the question.  I'd still
put
> > >> my
> > >> >> vote down for a static "storage" class.  I do that, read the data
in
> > >> a
> > >> >> plugin, stick it in the storage class, and I'm done.  The storage
> > >> class
> > >> >> is
> > >> >> pretty much nothing more than this:
> > >> >>
> > >> >> import java.util.HashMap;
> > >> >> public class AppConfig {
> > >> >>  private static HasMap config = new HashMap();
> > >> >>  public static void setConfig(HashMap config) {
> > >> >>    this.config = config;
> > >> >>  }
> > >> >>  public static HashMap getConfig() {
> > >> >>    return config;
> > >> >>  }
> > >> >> }
> > >> >>
> > >> >> I start my plugin by doing:
> > >> >>
> > >> >> HashMap config = AppConfig.getConfig();
> > >> >>
> > >> >> ...then read in whatever data I need, shove it in config, and
final
> > >> do:
> > >> >>
> > >> >> AppConfig.setConfig(config);
> > >> >>
> > >> >> Again, so long as this data isn't going to change, and it's not
a
> > >> huge
> > >> >> amount of data, that's all there is to it.  I don't know if this
> > >> would
> > >> >> be
> > >> >> considered "best practice', but it's certainly "common practive"
> > >> AFAIK
> > >> >> :)
> > >> >>
> > >> >> --
> > >> >> Frank W. Zammetti
> > >> >> Founder and Chief Software Architect
> > >> >> Omnytex Technologies
> > >> >> http://www.omnytex.com
> > >> >>
> > >> >> On Mon, February 14, 2005 2:08 pm, David Johnson said:
> > >> >> > Ah!
> > >> >> >
> > >> >> > After reading up on the Struts Plugins, I have the following
> > >> question
> > >> >> >
> > >> >> > Are struts plugins a perfectly acceptable way to handle Application
> > >> >> > level caching? How about best practices-wise?
> > >> >> >
> > >> >> > Thoughts?
> > >> >> >
> > >> >> > D
> > >> >> >
> > >> >> >
> > >> >> > On Mon, 14 Feb 2005 11:03:24 -0800 (PST), Martin Wegner
> > >> >> > <marty_wegner@yahoo.com> wrote:
> > >> >> >>
> > >> >> >> A PlugIn works nicely as well.  I am not sure which is
the
> > >> >> recommended
> > >> >> >> Struts practice.
> > >> >> >>
> > >> >> >>
> > >> >> >> --- Wendy Smoak <java@wendysmoak.com> wrote:
> > >> >> >>
> > >> >> >> > From: "David Johnson" <chachany@gmail.com>
> > >> >> >> > > I have a need in an app I'm working on to cache
data that is
> > >> >> valid
> > >> >> >> and
> > >> >> >> > > shared across users, like standard country
codes, region
> > >> codes,
> > >> >> >> > > industry codes... stuff like that.
> > >> >> >> > >
> > >> >> >> > > What's the best way to do that with my struts
1.2 application?
> > >> Is
> > >> >> >> > > there something built in that I'm not aware
of that I can
> > >> >> leverage
> > >> >> >> or
> > >> >> >> > > any best practices you guys can point me toward?
> > >> >> >> >
> > >> >> >> > I use a ServletContextListener that puts a bunch
of Maps and
> > >> other
> > >> >> >> > resources
> > >> >> >> > in application scope.  (Then I use a HttpSessionListener
to set
> > >> up
> > >> >> >> > user-specific things.)
> > >> >> >> >
> > >> >> >> > --
> > >> >> >> > Wendy Smoak
> > >> >> >> >
> > >> >> >> >
> > >> >> >> > 
> > ---------------------------------------------------------------------
> > >> >> >> > To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> > >> >> >> > For additional commands, e-mail: user-help@struts.apache.org
> > >> >> >> >
> > >> >> >> >
> > >> >> >>
> > >> >> >> 
> > ---------------------------------------------------------------------
> > >> >> >> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> > >> >> >> For additional commands, e-mail: user-help@struts.apache.org
> > >> >> >>
> > >> >> >>
> > >> >> >
> > >> >> >
> > >> >> > --
> > >> >> > -Dave
> > >> >> > ChaChaNY@Gmail.com
> > >> >> >
> > >> >> > ---------------------------------------------------------------------
> > >> >> > To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> > >> >> > For additional commands, e-mail: user-help@struts.apache.org
> > >> >> >
> > >> >> >
> > >> >>
> > >> >> ---------------------------------------------------------------------
> > >> >> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> > >> >> For additional commands, e-mail: user-help@struts.apache.org
> > >> >>
> > >> >>
> > >> >
> > >> >
> > >> > --
> > >> > -Dave
> > >> > ChaChaNY@Gmail.com
> > >> >
> > >> > ---------------------------------------------------------------------
> > >> > To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> > >> > For additional commands, e-mail: user-help@struts.apache.org
> > >> >
> > >> >
> > >>
> > >>
> > >
> > >
> > > --
> > > -Dave
> > > ChaChaNY@Gmail.com
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> > > For additional commands, e-mail: user-help@struts.apache.org
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> > For additional commands, e-mail: user-help@struts.apache.org
> >
> >
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org

-- 
_______________________________________________
Find what you are looking for with the Lycos Yellow Pages
http://r.lycos.com/r/yp_emailfooter/http://yellowpages.lycos.com/default.asp?SRC=lycos10


---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org


Mime
View raw message