temp temp,
If you are going to cache:
Use request scope for objects that should be cached for the duration of a single request servicing.
Use session scope for objects that should be cached for the duration of a user's session (more than one request) and that represent data unique to the user, or that represent common data that the user can modify, thus creating data that is then unique to the user.
Use application scope or static scope for everything else (remembering caveats of concurrent access -- typically this will be read-only data). If 100 users' shopping carts will contain the same Furby item and the Furby item is used for read only access, each session should (ideally) contain a reference to the same Furby instance -- there is no need for 100 identical Furbies to be instantiated (this suggests application scope caching, not session scope caching, though actually you may be accessing attributes in both scopes to accomplish this). When you use String literals as your cached values, this happens automatically (String class pooling), but if your cached objects are not String literals (or basically just wrappers for String literals), somewhere your code should see if Furby No. 13876 already has been instantiated before instantiating it (unless the Furby class is small and/or you don't care about such memory inefficiencies). It helps if you are caching in the middle tier rather than in the view tier.
A simple way to use session caching in the view tier is to associate a timestamp with the cached property (you might write a bass class "Cacheable", to be used as an attribute, that contains a data field and a timestamp field and that implements java.io.Serializable). Your view helper (or Action) checks the session for the object first. If it finds the object, it also checks the timestamp. If the object is missing or the timestamp is too old, you go and fetch the object from the middle tier, set/reset the timestamp and cache it. This is a simple way, and not necessarily a bad way, but probably not the best way. It might be the best way though if you are truly talking about data that is unique to each user (shopping cart, large inventory) and/or if you want something that is easy to understand and implement.
A lot of middleware products (such as iBatis, Hibernate) use caching in the middle/back end tiers, which frees your view helpers from having to worry about it. It's pretty easy to implement the caching strategy I mentioned in your own middle tier. Then not only will your view helpers be freed from it, but they can remain unchanged if you later decide to go to one of these middleware products. Typically the strategy here is to associate a data store query with a cached result.
Even better, if you like to roll your own, I recommend learning how to write an MRU cache (use a List and a Map, in cooperation, wrapped in a single class and instantiate as a singleton) and then let your middle tier manager components make Cacheables out of stuff that gets asked for repeatedly (good for things like stock quotes and news headlines). You can figure this out in a day or two, and now you can adjust your memory consumption/query frequency tradeoff. Compare that to however long it takes to learn iBatis or Hibernate. But if you don't feel comfortable with Threads, concurrency and Collections then I would say don't mess with this approach (again it's typically not difficult to implement if your data is read-only).
Everyone has a different opinion on this, so just take mine as one of them. But, on the question of whether you should cache at all, I would lean toward no until/unless you have a clear understanding of where it's going to improve the performance of your application. If your user keeps refreshing views of a shopping cart with the same contents (product descriptions), or something similar, then your scenario might be a good candidate for a caching strategy.
Hope that helps, Erik
temp temp wrote:
Is it similar to sessions ie each user will have his own cached Object or all the users share the same
Cached object .
I have a jsp with multiple submit buttons .Each submit
button calls database to get data. Its like I have
3 submit buttons 1st gets User comments .
2nd gets some results of a type
3rd gets some results of a different type
when user clicks on comments 1st submit button I have
to call 2nd and 3rd to get result data .I want to
avoid this by caching the results data .This
results data is different for different users. User I
mean a client(Browser) accessing my website.
Should I use sessions to store this data or use Cahced objects in case cached object what to use.
thanks & regards
__________________________________ Do you Yahoo!? Yahoo! Mail - Helps protect you from nasty viruses. http://promotions.yahoo.com/new_mail
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
