5 Replies Latest reply on Mar 10, 2005 10:00 AM by Collin

    Commit option A causing issues with cache not updating

    Collin Novice


      For the purpose of this example, assume I have two entities, X and Y, where Y has a fk mapping to X such that:

      Entity X:
      public abstract Y getY();
      public abstract void setY(Y y);


      Entity Y:
      public abstract java.util.Collection getXs();
      public abstract void setXx(java.util.Collection xs);

      I have management routines with session facades (Required transaction type) for both types of entities, which appear to be working fine. I can make updates to both types X and Y and upon re-editing the entities I see the changes reflected.

      However, using Commit option A with MS SQLServer as my data store, I am seeing an odd behavior:

      1) I edit entity Y1, changing all of the CMP fields using a session facade with Required transaction attribute. I check the database to verify that the data has been updated on the database and it has.

      2) In a future thread I obtain a reference to an instance of X which has a non-null rerference to Y1 using xHome.findByPrimaryKey(id).

      3) calling xEntity.getY() results in an instance of Y for which all of the CMP fields are old and out of date (before step 1). There is only one instance of Y in the database, and looking at the primary key of Y verifies that I'm not looking at a different entity.

      Now, if I change my commit option to type B, then this oddness goes away. This leads me to believe it's an issue with caching at the CMP/EJB level.

      Strangely, though, I've been using jboss3.2.3 for quite some time now and have not seen this behavior before. Any ideas on what I might be doing wrong? I don't want to use commit option B because it's just too slow.

      Any help appreciated.


      MSSQLServer 2000
      Commit option A
      JBoss 3.2.3, Windows XP