1 Reply Latest reply on Oct 13, 2005 5:21 AM by Niklas Nobel

    commit-option B read-only without cache

    Niklas Nobel Newbie

      Hi!

      Im currently working with a system dependant upon jboss-3.0.4. Entity beans are using commit-option B and getters are declared read-only to avoid unneccesary locking. The problem is that the instance cache is then being used for those getters (actually the case even with commit-option C). Getters using cached data are unwanted so a workaround has been constructed using a different cache policy than the ordinary LRU policy. This cache policy passivates the entity as soon as the entity is added to the cache! Code looks like

      public void insert(Object key, Object object) {
       //m_cache instanceof AbstractInstanceCache
       m_cache.release((EnterpriseContext)object);
       }
      


      To me this seems odd. There must be a smarter way to turn off the cache and still have the "read-only non locking" behaviour for getters. Comment anyone?

        • 1. Re: commit-option B read-only without cache
          Niklas Nobel Newbie

          In a situation where you dont own the database and need to see changes in "realtime", you are forced to use commit-option b or c. The problem is that the standard container configuration for entity beans leads to heavy locking if simultaneous transactions uses the same entity bean. To avoid heavy locking you declare getters as read-only. Unfortunately those getters will use the cache and then you will not see the changes in "realtime".

          I've switched to using another container configuration for entity beans, entity per transaction. Then I dont need the read-only getters and the locks are gone.

          Dont try the cachepolicy code shown in the previous post, its an antipattern.

          /2n