AnsweredAssumed Answered

Share sitedata remote persister cache

Question asked by jpotts Moderator on Oct 18, 2010
Latest reply on Dec 21, 2010 by berenicestr69
I need to be able to set any user's dashboard using a web script invoked from curl. I've looked at the web script that the customize dashboard dialog posts to. My first approach was to post similar JSON to that script. Unfortunately, although you don't get an error, through the debugger I can see that the remote store is rejecting the persister's associatePage, unbind, and bind component calls with a 404 not authorized. I tried calling the Share tier web script with user/password in the header and by using a ticket instead, but nothing helped. I even tried setting the web script to do a runas admin but I'm not sure that is supported in the Share tier. I basically gave up on this approach having decided that I do not understand what's going on from an authentication perspective on the Share web script tier.

So, I decided to use a second approach which is to simply create the same XML in the AVM store on the repo tier that the persister would have. This actually works great. I can call my repo tier web script with JSON similar to what was being posted on the Share tier, and my web script creates the dashboard.xml and component XML files in the AVM sitestore.

The issue is that there is a cache on the Share tier that is holding on to the data objects. The persister classes have a method called invalidateCache, so my attempt to fix this was to create a Surf tier web script that calls the invalidateCache method. (Luckily, this doesn't require any authentication). This does seem to clear the cached components but it is not clearing the cached template instance reference.

In other words:
0. Start with a user with a two column dashboard, two dashlets in each column.
1. Run repo tier web script to create page and component XML, switching the two column layout to a one column layout and eliminating all but one component.
2. Log in to Share.
3. Old dashboard is still visible (as expected) because the surf tier cache still has the old data objects.
4. Run share tier web script to clear the cache.
5. Log out of and back into Share.
6. The dashboard now shows the correct components (just the one we reduced to) but still the two column layout (an empty second column is showing).
7. Restart Share tomcat. Log in. Now that the memory is cleared, the dashboard is correctly showing the one dashlet in the one column layout.

So, it appears to be holding on to the dashboard.xml page data object which is where the template instance is specified.

My "clear cache" web script in the Share tier is simple:
<bean id="" parent="webscript" class="com.obscured.share.admin.ClearCacheGet">
       <property name="persisters">
               <ref bean="webframework.objects.persister" />

And the webscript:

public class ClearCacheGet extends DeclarativeWebScript {

   // Dependencies
   private List<ModelObjectPersister> persisters;

   protected Map<String, Object> executeImpl(WebScriptRequest req, Status status, Cache cache) {
        Map<String, Object> model = new HashMap<String, Object>();

        for (ModelObjectPersister persister : persisters) {
           if (persister instanceof CachedPersister) {

        return model;

   public void setPersisters(List<ModelObjectPersister> persisters) {
      this.persisters = persisters;

Incidentally, if I run the process again, but this time, switch from a one column layout with one dashlet to a two column layout with four total dashlets, after the cache is cleared I can log in and see that the layout is still one column, but contains the correct components for that column. Restarting tomcat resolves the issue and shows the expected two-by-two dashboard.

Maybe the page object is being cached somewhere that my cache clearing web script doesn't touch?


PS. This is 3.4a community.