2 Replies Latest reply on Oct 13, 2008 5:15 AM by manik

    JBCACHE-1423 Fix

    brian.stansberry

      Discussion of https://jira.jboss.org/jira/browse/JBCACHE-1423 -- see JIRA description for background.

      The "simple fix" I discuss on the JIRA solves the out-of-date state problem, but breaks a number of other unit tests:

      o.j.c.loader.UnnecessaryLoadingTest.testDontLoadWhenKeyInMemory()
      o.j.c.loader.UnnecessaryLoadingTest.testUnnecessaryMultipleLoading()
      o.j.c.mgmt.CacheLoaderTest.testCacheLoaderMgmt()
      o.j.c.mgmt.PassivationTest.testPassivationMgmt()

      In the first two there are specific assertions that a put(Fqn, Map) call doesn't result in a cache loader load. The latter two fail because the test setup does a bunch of put(Fqn, Map) calls and the tests assert that this didn't result in any cache loader misses; w/ my fix it does.

      Bottom line, my simple fix results in cache loader get() calls that weren't there before. So, hopefully you guys have a better solution. ;) One possibility is what I mentioned on the JIRA -- change CLI.loadNode so it doesn't overwrite existing in-memory key/value pairs with those from the persistent store.

      I'll check in the unit test for this.

        • 1. Re: JBCACHE-1423 Fix
          brian.stansberry

          Looking in trunk, where the JBCACHE-1368 work did something very much like what I propose as the 2.2.X "simple fix", I see that the above mentioned tests have been altered to assert the behavior that occurs in a patched 2.2.X.

          So, any objections to my committing the "simple fix" and changing the 2.2.X assertions?

          • 2. Re: JBCACHE-1423 Fix
            manik

            Yeah altering the tests is fine by me, Brian. As you've noticed I've done the same on trunk.