EJBStore in Transactions

Discussions

EJB programming & troubleshooting: EJBStore in Transactions

  1. EJBStore in Transactions (3 messages)

    Hi

    I have some audit fields (dateLastAmended and userLastAmended) on every bean. In my ejbStore method, I update these fields. However, what i experience is that at the end of a transaction, my container (JBOSS 3.04), calls ejbStore, even if the bean has not been changed ie. all beans that have been accessed during the transaction have their ejbStore methods called, whereas I would think only those that have changed should be updated.

    Is this behaviour correct, and if so, does anyone have any thoughts/ideas on how I can update the audit fields of only those beans that have changed?

    Regards
    Chris

    Threaded Messages (3)

  2. EJBStore in Transactions[ Go to top ]

    If you are using BMP then the container generally has no way to know which fields changed. You can do it yourself by having a boolean "instanceUpdated" flag, reset it on ejbLoad, and set it whenever you change something. When ejbStore is called, only update the database is the flag is set.

    Gal
  3. EJBStore in Transactions[ Go to top ]

    Hi Gal

    No, I am using CMP.

    Regards
    Chris
  4. EJBStore in Transactions[ Go to top ]

    A team I'm working on is also facing the same problem.

    We're using CMP and we have the same types of audit fields. Ideally, we'd like to be able to hook into the container within the ejbStore() method to do a test to see whether or not the entity bean has been modified before calling the set methods on our audit fields.

    (Ideally, the container would only call the ejbStore() method when the entity has actually changed but this is not the case.)

    It doesn't appear that CMP 2.0 supports this type of functionality. We've come to the conclusion that we're going to have to maintain our own dirty flag on the entity bean. Unfortunately, the set methods are abstract using CMP 2.0 so the code to manage the dirty flag is going to have to reside in a DTOFactory that calls the "set" methods on the entity bean. Cumbersome and ugly.

    If anyone else knows of a better solution...please post.