Announcement Announcement Module

Spring Modules forum decommissioned in favor of Spring Extensions

As the Spring Modules project has been replaced by the Spring Extensions ( project, this forum has been decommissioned in favour of Spring Extensions one at:

Please see the Spring Extensions home page for a complete list of current projects in Java, .NET and ActionScript. You can also propose one if you want.

Costin Leau
SpringSource - Spring Training, Consulting, and Support - "From the Source"
See more
See less
Can I flush a single entry in osCache? Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Can I flush a single entry in osCache?

    it seems that the OsCacheFacade only supports flushing groups, and not specific entries (see the onFlushCache method). After I update a single row in the database, I only want to flush the corresponding entry. And I don't necessarily want to define a group for each entry. And even if I did, I don't think I can, because the cachingModel does not allow this. Of course, I can subclass the facade and provide my own implementation for the onFlushCache method, but I wanted first to verify that I'm not missing something.

    Thanks in advance.

  • #2
    The GeneralCacheAdministrator has a flushEntry method. If you are using the OsCacheManagerFactoryBean it returns an instance of the GeneralCacheAdministrator.


    • #3
      I think the whole design is problematic

      After looking some more at the code, I think the problem goes deeper than my original observation. I find this design problematic, for several reasons:

      First, the flush interceptor flushes the whole cache (or group, but it's the same in this case) for every entry that is updated. This is very inefficient, because if I have a cache of 1000 records - all of them will be flushed every time I update any single one of them.

      There is no way to provide a more fine grained flushin behavior, because the key used for the cache is a hash of the method invocation itself, and not the id of the entity being cached. Therefore, the load() and the save() methods, for the same entitiy, will yield two different keys and there is no way for the flushing to be more accuarte than it is now.

      And in any case, the fact that the generated cache key is completely unrelated to the business id of the cached object is, in my opinion, a serious drawback on its own.

      I was initially very glad to find this solution, because caching does seem to be suitable for an AOP-based declarative configuration, but I don't think I will be able to use this after all.

      If any of the SpringModules developers is reading this, I will be happy to hear your toughts on the matter, and please do not be offended by my criticism.


      • #4
        I have exactly the same question with Spring modules v0.4.

        Each entry of my cache caches a Client transfer object returned from a web service method : getClient(ClientId).

        I want to remove one cache entry when I call the methods remove(ClientId) our update(Client) and not the whole cache.

        Since spring modules caching supports only supports flushing groups, I think I can't do this without having to rewrite a lot of code (perhaps I'm missing a point).

        Is there a possible issue, or will the springmodules developing team be going to add support for this feature ?



        • #5
          This could accomplished by creating an interceptor that takes a caching model but removes the item from the cache instead of getting the item from the cache. Unfortunately, since invoke is a final method in the interceptor, you can't override it without changing the source. But it shouldn't be hard to do.


          • #6
            Since spring modules caching supports only supports flushing groups, I think I can't do this without having to rewrite a lot of code (perhaps I'm missing a point).

            Is there a possible issue, or will the springmodules developing team be going to add support for this feature ?
            Raise an issue on Spring Modules JIRA please.


            • #7
              It already exists as MOD-165. Its currently on the 0.6 roadmap.


              • #8
                Costin --

                What is the status of this discussion? It is a very interesting one.

                I too was surprised when I first learned that there is no mechanism for invalidating/removing single entries from the cache. Instead, the only way to invalidate cache entries when an "update" is done is by flushing the entire cache!

                I understand that this may entail a fairly big architectural change to the project, and was wondering if any of the spring-modules developers are talking about this issue.

                Thank you!



                • #9
                  The issue is definitely a big one for the Caching module however, the current maintainer has just took over the project and it will take a while until he will start fixing issues faster.
                  Patches and contributions in this area are welcomed.


                  • #10
                    Ive taken a quick dig through the source code, and it seems to me that the main things missing are flushing models and CacheProviderFacade implementations that support flushing of individual entries in the cache (ive only looked at the OS Cache implementations).

                    If "OsCacheFacade.onFlushCache(FlushingModel model)" was modified to allow flushing of single items (currently it only flushes groups), we could provide it with an implementation of "FlushingModel" that specified rules for removing individual items in the cache (from specific groups?).

                    Now heres where I get lost:

                    The AbstractFlushingInterceptor (used in the CacheProxyFactoryBean - NameMatchFlushingInterceptor) could be modified so that the CacheProviderFacade.flushCache() was told which entry to remove from the cache. Alternatively an implementation of AbstractFlushingInterceptor.getModel(MethodInvocat ion methodInvocation) could be provided - returning a FlushingModel stating which entry in the cache to remove.

                    Both of the above seem to involve a lot of core source changes though.