There's already an issue raised regarding a configurable cache mechanism (TRINIDAD-780) to allow the view cache to be externally managed - I'm assuming that request was also related to your issue. While I've not seen any feedback from other members on their opinion of such an enhancement, I can see the benefits, and it could potentially provide a good-enough failover.
Members, we'd really welcome any feedback on this topic as the state cached on the server-side is pretty significant. Additionally, if there are any other optimizations others can bring to this around clearing out old view caches - e.g. Could we keep just the most recent one for each conversation/frame that is open, rather than just caching a given number - perhaps at the cost of back-button support. Also, are there other options we could look at around optimzing the state that is cached, as I've seen comments about Facelets (which is used in this case) already holding much of the same information, or even ideas such as caching state deltas. Regards, D. On 10/31/07, Danny Chen < [EMAIL PROTECTED]> wrote: > > 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. > -- Chordiant Software Inc. www.chordiant.com
