[
https://issues.apache.org/jira/browse/TRINIDAD-816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12542939
]
hanasaki jiji commented on TRINIDAD-816:
----------------------------------------
Along the lines of software engineering and patterns, Danny, would you consider
making your skeleton solution based on the same concepts as JDBC and JNDI and
Java Cryptography? ie: A common generic cache API with a configuration file?
This would allow for the "providers" you mention in an extensible manner at
runtime using reflection to load the specific provider class. The generic
cache API might be as simple as a Map subinterface called CachingMap since the
get/put/remove operations are so key to the concept of what a cache
functionally provides. I realize that using a subinterface will require
perhaps a parallel set of small classes like "CachingHashMap" however these
small wrappers may be necessary to maintain the programing semantics of caching
and considering any unknown future Map implementation automatically to be IsA
cache is a bit scary. It also allows for new methods such as "fush" and
"invalidate" and "invalidate(String key)"
> Externalizing the ViewCache (currently the view cache is stored in the http
> session, this enhancement to to add an option to the framework to move the
> view cache to some other external cache system)
> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: TRINIDAD-816
> URL: https://issues.apache.org/jira/browse/TRINIDAD-816
> Project: MyFaces Trinidad
> Issue Type: Improvement
> Components: Archetype
> Environment: all
> Reporter: Danny Chen
>
> From email:
> **************************
> We like to propose an enhancement to how and where Trinidad maintains its
> view caches. Currently when the system is configured to use token as the
> state persistent method, Trinidad will maintain all component states in a
> ViewCache. This ViewCache is just a map that is maintained in the
> HttpSession. Each page has its own View Cache map. There could be a number
> of ViewCaches stored in a session if multiple frames are being used (which we
> have). During performance testing of our app, we find that this view cache
> consumes a lot of memory. More then 60% of the session memory is occupied
> by the View Cache. With more then 600k in session memory, we can't ensure
> fail over work appropriately and consistently. We tried to use the "all"
> option for client _state_method. But the increase in download time is
> outside of our max threshold.
> After looking through the Trinidad code, we come up with a design to move the
> view caches outside of the session and maintain them in a configurable cache.
> The benefit of this solution is the fact the ViewCache is not in the
> session. Thus, we don't have to replicate them even if we turn on session
> replication. In the case of session fail over, the user would see the pages
> refresh. The user would have to hit submit again to move on to the next.
> Which cache implementation to use, which cache region to use and what the
> expiration is can be configurable through xml. All these logic is controlled
> by a new option (token_external_cache) in CLIENT_STATE_METHOD. These changes
> should be very isolate. We will make most of the changes in
> org.apache.myfaces.trinidadinternal.application.State. This class is where
> the ViewCache is created and used. We would also introduce a new class
> similar to org.apache.myfaces.trinidadinternal.util.TokenCache, call it
> TokenExternalCache. TokenExternalCache will contain all integration logics
> to add/update/read data from the configured cache. If application view cache
> is enabled, none of these logics will get executed.
> We don't' foresee any major difficulty in implementing this solution. And we
> don't foresee any side effort as well. Please let us know what Trinidad
> community think. More importantly please let us know if the Trinidad
> community is welling to accept this solution and get it integrated in a
> future release or not.
> ********
> for more info, refer to 11/2007 developer mailing list.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
