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.
