RE: [Trinidad] Proposal to Externalize the ViewCache.

[Danny Chen <Da...@chordiant.com>]

Hi All,

 

It would be great if I can get some comments and/or suggestions based on
this proposal.  We can provide a more detailed design if needed.  What
we need now to move forward is a buy in from the Trinidad community.
Once we have that, we can move forward with implementation based upon
the agreed design.  

 

Enclosed is a chart of how much session memory we can save if the
ViewCache is externalized.

 

Thanks,

Danny Chen

 

________________________________

From: Danny Chen [mailto:Danny.Chen@chordiant.com] 
Sent: Wednesday, October 31, 2007 12:29 PM
To: dev@myfaces.apache.org
Subject: RE: Proposal to Externalize the ViewCache.

 

Hi All, 

 

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.

 

Thanks,

Chordiant Engineers.

 

The information transmitted herewith is sensitive information of
Chordiant Software or its customers and is intended only for use to the
individual or entity to which it is addressed. If the reader of this
message is not the intended recipient, you are hereby notified that any
review, retransmission, dissemination, distribution, copying or other
use of, or taking of any action in reliance upon, this information is
strictly prohibited. If you have received this communication in error,
please contact the sender and delete the material from your computer.