Yeah, good invalidation cache (what uP does most everywhere) practice is to
remove the cached data on write or delete and cache on read.


On Tue, Mar 4, 2014 at 7:15 AM, Andrew Petro <[email protected]> wrote:

>  Ah.  The layout cache is invalidated at DistributedLayoutManager instance
> init, so long as afterPropertiesSet() is called:
>
> http://goo.gl/2CMW7t
>
> and afterPropertiesSet() will be called, since it's an InitializingBean
> and DLM is being instantiated by Spring:
>
> http://goo.gl/UPdqTD
>
>
> There goes that hypothesis.  Thanks.
>
> Eric, you still figure saveLayout() should be invalidating the cache, even
> though that's not my particular ghost in the machine?
>
> Andrew
>
>
>
>
> On 3/4/14, 8:57 AM, Eric Dalquist wrote:
>
> That should be invalidating the cache but the layout should also be
> removed from the cache at both login and logout as well.
>
>
> On Tue, Mar 4, 2014 at 5:17 AM, Andrew Petro <[email protected]> wrote:
>
>> uPortal developers,
>>
>> Do you suppose that DLM saveUserLayout()
>>
>> http://goo.gl/kRxyqz
>>
>> ought to be invalidating the layout cache so that the saved layout is
>> read back from the layout store on next access?
>>
>> I suspect yes.
>>
>> I think I'm seeing goofiness where user changes to received DLM fragments
>> (as in, deleting them from the personal layout) take immediate effect and
>> persist to the database, but *don't* reflect on logout and log-back-in
>> without Tomcat restart.  I suspect this is because the in-user-session
>> cached copy is being properly updated and the changes are being persisted
>> to the database, but they're not being pushed into that cache.  I hope
>> simply invalidating the cache on save is going to be a reasonable solution
>> (rather than heroically injecting just the right new data into the cache
>> without round-tripping from the layout store).
>>
>> I hope to have a cogent explanation and a pull request today. But hey, if
>> you already know I'm going in the wrong direction on this, do a fellow a
>> solid and let me know? :)
>>
>> Credit due to Tim Levett for the insight that the ghost in the machine
>> I'm seeing might be due to this particular cache.
>>
>> Andrew
>>
>>
>>
>> --
>> 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
>
>
> --
>
> 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

Reply via email to