Cache-backed layouts = happy JHU folks, for all of the benefits outlined by Drew and more... +1
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Drew Wills Sent: Tuesday, July 08, 2008 11:32 AM To: [email protected] Subject: [uportal-dev] LAYOUT_CACHE: Is this an interesting enhancement? Hey folks, I'm working at JHU, and we've put together an enhancement to DLM: the ability to store users' layouts in a standard, portal managed cache. Currently users' layouts are stored (at least in DLM) as a member variable on each user's LayoutManager instance. This situation means that: - User layouts never change until (1) the user makes a manual change, or (2) the user logs in again - There's no way to manage in-memory layout data administratively With this enhancement, you'd be able to: - specify that user layouts should expire and be rebuilt, say, 15 min after creation or after 10 min of "idle" time (i.e. not used for 10 min) - specify that no more than, say, 500 layouts should be held in memory at one time - use JMX to "clear" (drop) all the layouts in a running instance of uPortal - write Java tools that intelligently invalidate individual layouts (or all layouts) when certain portal events happen The changes are relatively small & encapsulated, so they're unlikely to "break" existing features or even custom Java tech that integrates with DLM. I'm attaching a .patch that shows the delta. Please share thoughts on whether this enhancement is desirable or even acceptable. If there's interest, I'll create the JIRA etc. drew wills -- You are currently subscribed to [email protected] as: [EMAIL PROTECTED] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev -- You are currently subscribed to [email protected] as: [EMAIL PROTECTED] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
