2 Replies Latest reply on Sep 14, 2004 3:48 PM by bdbogg

    Duplicate entity instances, differing field values (caching

    bdbogg

      Searched quite a bit to find an answer to this problem, so please let me know if it's already been answered...

      I'm using CMP, with commit-option A (JBoss 3.2.5). I have some container managed relationships (CRM) set up. As a conceptual example similar to my own, a box contains many gadgets, each of which contains many widgets. Here's the scenario where I'm experiencing the problem:

      I look up a box entity, then iterate through all its gadget entities and all of their widget entities. Later on (in a different transaction), I use a finder method (not the primary key finder) to directly find a particular widget entity, and update its state. (I can verify that this is being updated in the database just fine). However, if, in yet another transaction later on, I use the CMR structure described above to access the same particular widget entity, it still has the old value. I verified (using toString on the entity object) that there are two separate entity instances representing the same database row (one when I found the widget directly, the other when I got it through the CMR hierarchy), but the original entity didn't get updated. I also verified that both entity instances have the same primary key (simply a string value). The database got updated, but one of the entity instances didn't stay in sync.

      Is this expected behavior? I'm not too familiar with the JBoss entity caching or CMR internals, so maybe I'm missing something important.

      (Note that the database is not being updated by anything but JBoss.)

      Thanks!

      (Using JBoss 3.2.5, Windows 2000, Sun JVM 1.4.2_03.)

      -Daniel Boggs

        • 1. Re: Duplicate entity instances, differing field values (cach
          bdbogg

          For the sake of clarification, say I have an Account entity bean, which has a collection of EmailAddress entity beans (1 to many container managed relationship).

          A client calls a method getAcctInformation() on a session bean. This method looks up the Account bean, and iterates over the EmailAddress beans (retrieving the information to send back to the client).

          A client then calls a method updateEmailInfo() on a session bean, to update one of the EmailAddress records retrieved above. This method looks up a particular EmailAddress bean (directly, via a finder), and modifies its state. This is persisted to the database with no problems.

          Now, when the client calls getAcctInformation() again, it still gives back the old information for that particular EmailAddress (not what is in the database).

          Is there a way to invalidate the old bean instance? Why does it not stay in sync with the update? Is there a difference in caching when using CMR and not using CMR?

          If anyone has an idea of things I might be able to investigate in order to further debug this issue, it would be greatly appreciated. Thanks.

          (Note: I'm not using clustering.)

          Daniel Boggs

          • 2. Re: Duplicate entity instances, differing field values (cach
            bdbogg

            I did find a workaround for this problem (see below), but I still have no idea why the original problem would be happening, or what the root of the problem really is.

            One other bit of information that might be helpful in resolving: if I restart the server, the problem goes away. In other words, the problem only seems to occur if the data in question was created during the same server session (where "server session" = a particular run of the app server, between restarts).

            Workaround:

            For the particular bean which was not staying in sync, I configured it in jboss.xml to use the default "Instance Per Transaction CMP 2.x EntityBean" configuration (which uses commit-option C). This ensures the entity instance stays up-to-date. [See the Wiki at http://www.jboss.org/wiki/Wiki.jsp?page=CMPCaching for details about instance caching and commit options.]

            It would be nice to keep commit-option A, though.

            If anyone knows of a better solution, please let me know. It seems a shame to have to resort to commit-option C in this case.

            Thanks.

            Daniel Boggs