castor
  1. castor
  2. CASTOR-1487

Castor EHCache implementation non-working

    Details

    • Type: Bug Bug
    • Status: Closed Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.0.1
    • Fix Version/s: 1.0.3
    • Component/s: General
    • Labels:
      None
    • Number of attachments :
      2

      Description

      We're currently hacking together the EHCache version of Castor's impl - only it's broken. The following errors exist in EHCache.java

      • The initialize method is missing. This is because the parent's AbstractBaseCache initialize ends up being the visible one. Add the following:

      public void initialize(final Properties params) throws CacheAcquireException

      { initialize(IMPLEMENTATION, params); }

      and your actual initializer will get called.

      • Errors during initialization: - TYPES_NO_PARAM doesn't work; remove it. getMethod(String) should be used anywhere it was used, without parameters applied.
      • In EHCache 1.2, at least - I haven't tested older versions - the net.sf.ehcache.Element.getObjectValue() doesn't exist - you want getValue().
      • Error in get: NPEs when things don't exist.
      • You'll note that elementInCache is not null checked; but null is a valid response for when there is no cache entry. You need to test for null
        before calling _getObjectValueMethod.invoke()

      Any chance of getting this into 1.0.2?

      1. patch.c1487.20060830.txt
        4 kB
        Werner Guttmann
      2. patch-C1487-20060802.txt
        4 kB
        Ralf Joachim

        Activity

        Hide
        Ralf Joachim added a comment -

        Hi Gregory, I'll try to resolve this for 1.0.2 with some help from your side.

        Show
        Ralf Joachim added a comment - Hi Gregory, I'll try to resolve this for 1.0.2 with some help from your side.
        Hide
        Werner Guttmann added a comment -

        Let me know whether you'd need any input.

        Show
        Werner Guttmann added a comment - Let me know whether you'd need any input.
        Hide
        Ralf Joachim added a comment -

        Gregory can you please review and test attached patch?

        Having said that I used getMethod(String, null) instead of getMethod(String) as the later is not available at Java 1.4.

        Show
        Ralf Joachim added a comment - Gregory can you please review and test attached patch? Having said that I used getMethod(String, null) instead of getMethod(String) as the later is not available at Java 1.4.
        Hide
        Ralf Joachim added a comment -

        Committed patch as is.

        Show
        Ralf Joachim added a comment - Committed patch as is.
        Hide
        Gregory Block added a comment -

        Looks like I missed something else.

        Element objects are held in cache and can be retained, even though they're not actually purged from the system yet and may be expired.

        That means that when you fetch the Element object, you must test it to see if it's up to date before returning it.

        To do this:

        1) Up at the top, under _getValueMethod
        /** The method to test whether or not an element is expired. */
        private Method _isExpiredMethod;

        2) in the initializer, just under the _getValueMethod setup,
        _isExpiredMethod = _elementClass.getMethod("isExpired", null);

        3) In the get() call, the contents of the try should look like
        Object elementInCache = _getMethod.invoke(_cache, new Object[]

        {key}

        );
        if (elementInCache == null)

        { return null; }

        if (_isExpiredMethod.invoke(elementInCache, null)==Boolean.FALSE)
        result = _getValueMethod.invoke(elementInCache, null);

        You'll probably want to write a test case that explicitly creates an entry, clears the cache, and then uses isCached() to test to see whether or not it's cached. If you're lucky, it'll start working for you. I don't know, but it's possible that other caches will have similar behaviour, and expect you to be responsible for testing the difference between something-in-cache-but-expired and something-missing-from-cache.

        Show
        Gregory Block added a comment - Looks like I missed something else. Element objects are held in cache and can be retained, even though they're not actually purged from the system yet and may be expired. That means that when you fetch the Element object, you must test it to see if it's up to date before returning it. To do this: 1) Up at the top, under _getValueMethod /** The method to test whether or not an element is expired. */ private Method _isExpiredMethod; 2) in the initializer, just under the _getValueMethod setup, _isExpiredMethod = _elementClass.getMethod("isExpired", null); 3) In the get() call, the contents of the try should look like Object elementInCache = _getMethod.invoke(_cache, new Object[] {key} ); if (elementInCache == null) { return null; } if (_isExpiredMethod.invoke(elementInCache, null)==Boolean.FALSE) result = _getValueMethod.invoke(elementInCache, null); You'll probably want to write a test case that explicitly creates an entry, clears the cache, and then uses isCached() to test to see whether or not it's cached. If you're lucky, it'll start working for you. I don't know, but it's possible that other caches will have similar behaviour, and expect you to be responsible for testing the difference between something-in-cache-but-expired and something-missing-from-cache.
        Hide
        Werner Guttmann added a comment -

        Greg, mind attaching a patch, as you are using ehcache ?

        Show
        Werner Guttmann added a comment - Greg, mind attaching a patch, as you are using ehcache ?
        Hide
        Gregory Block added a comment -

        I'm afraid I'm in no position to do so - I can't do the additional testing and the rest of it, as I'm trying to get out of my current job; as such, my ability to work on third-party projects in any real capacity is in limbo, and I can't do the necessary checkout. As it is, I'm stuck perusing files via the SVN HTTP interface on codehaus.

        Show
        Gregory Block added a comment - I'm afraid I'm in no position to do so - I can't do the additional testing and the rest of it, as I'm trying to get out of my current job; as such, my ability to work on third-party projects in any real capacity is in limbo, and I can't do the necessary checkout. As it is, I'm stuck perusing files via the SVN HTTP interface on codehaus.
        Hide
        Werner Guttmann added a comment -

        Gregory, I'll try to get your last 'patch' committed in due time. Can I ask you for a favour, though ? Can you please point me to a URL or similar where I could read up on the subject of expiration and ehcache ?

        Show
        Werner Guttmann added a comment - Gregory, I'll try to get your last 'patch' committed in due time. Can I ask you for a favour, though ? Can you please point me to a URL or similar where I could read up on the subject of expiration and ehcache ?
        Hide
        Werner Guttmann added a comment -

        And yet another patch ....

        Show
        Werner Guttmann added a comment - And yet another patch ....

          People

          • Assignee:
            Werner Guttmann
            Reporter:
            Gregory Block
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Time Tracking

              Estimated:
              Original Estimate - Not Specified
              Not Specified
              Remaining:
              Remaining Estimate - 0 minutes
              0m
              Logged:
              Time Spent - 30 minutes
              30m