Uploaded image for project: 'JBoss Enterprise Application Platform 4 and 5'
  1. JBoss Enterprise Application Platform 4 and 5
  2. JBPAPP-4895

HHH-5490 dirty data be inserted into 2L cache

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed (View Workflow)
    • Priority: Major
    • Resolution: Done
    • Affects Version/s: EAP 5.0.1.CR3, EAP 5.0.1, EAP_EWP 5.1.0_CR1, EAP_EWP 5.1.0_CR2, EAP_EWP 5.1.0_CR3, EAP_EWP 5.1.0
    • Fix Version/s: EAP_EWP 5.1.1
    • Component/s: Hibernate
    • Labels:
      None
    • Affects:
      Release Notes
    • Workaround:
      Workaround Exists
    • Workaround Description:
      Hide

      refresh is generally used for generated properties.
      refresh is not required when @Generated annotation is used.
      I did a test with @Generated (so removing .refresh call) and it works.

      Second workaround: manually evicting the new cache entry.

      Show
      refresh is generally used for generated properties. refresh is not required when @Generated annotation is used. I did a test with @Generated (so removing .refresh call) and it works. Second workaround: manually evicting the new cache entry.
    • Release Notes Text:
      Hide
      When a <methodname>refresh()</methodname> method was invoked immediately prior to an <methodname>insert()</methodname>, and second-level caching was enabled, the entity was inserted into the second-level cache. If the <methodname>refresh()</methodname> committed successfully, however, the cached data was not automatically evicted. This occurred because <methodname>refresh()</methodname> did not track entity state. <methodname>refresh()</methodname> now tracks entity state, and evicts the cached data on a successful commit.
      Show
      When a <methodname>refresh()</methodname> method was invoked immediately prior to an <methodname>insert()</methodname>, and second-level caching was enabled, the entity was inserted into the second-level cache. If the <methodname>refresh()</methodname> committed successfully, however, the cached data was not automatically evicted. This occurred because <methodname>refresh()</methodname> did not track entity state. <methodname>refresh()</methodname> now tracks entity state, and evicts the cached data on a successful commit.
    • Release Notes Docs Status:
      Documented as Resolved Issue

      Description

      code is as follow

      TransactionManager tm = (TransactionManager) new InitialContext().lookup("java:/TransactionManager");
      tm.begin();
      MyEntity e = new MyEntity();
      em.persist(e);
      em.flush();
      em.refresh(e);
      tm.rollback();

      refresh invocation seems to break cache consistency. If refresh is used just before rollback, there is a cache entry (you can see it thanks to following code)

      tm.begin();
      em.clear();
      Session s = (Session)em.getDelegate();
      SessionFactory sf = s.getSessionFactory();
      Map cacheEntries = sf.getStatistics()
      .getSecondLevelCacheStatistics("test")
      .getEntries();
      tm.commit();

      Test done with a very simple entity + HashTableCacheProvider, so I guess the problem in is core or somewhere 'around' refresh implementation.

        Gliffy Diagrams

          Attachments

            Activity

              People

              • Assignee:
                stliu Strong Liu
                Reporter:
                AnthonyHib Anthony Patricio
                Writer:
                Misty Stanley-Jones
              • Votes:
                0 Vote for this issue
                Watchers:
                2 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: