ejbStore and DB2 Update triggers

[Sean Erwin]

I have an application that has the following scenario.
we have an CMP entity bean called account. It gets created and we retrieve and accouint record from the database. For some reason it appears that the bean immediately passivates and calls ejbStore. This call to ejbStore results in an update to the database eventhough the data has not changed. This update also causes update triggers set on certain database fields to fire eventhough the record has not been modified. Any ideas why
1. The bean is passivating immediately after retrieving the data?
2. I understand that whenever the beanm passivates it always calls ejbStore. This causes extra updates to the database and since we use update triggers to maintain an audit trail on each row, this screws upo our audit trail. How can one take advantage of update triggers in DB2 if this is how the container workls?
Thanks

[Sean Erwin]

Sorry
running Websphere 4.01 on OS/390 with db2 7.1 on os/390
Thanks
Sean

[Kyle Brown]

How are you using the CMP bean? Is the access wrapped in a Session bean? Are you directly accessing the CMP from a Servlet?
Kyle

[Sean Erwin]

Kyle we are using a session facade patter so access is wrapped in a session bean

[Kyle Brown]

Ah, I think I might know what the answer is. The behavior you are describing (updating an entity at the end of a trasnsaction even though you didn't modify it) is in fact, what the EJB specification says an Entity bean is supposed to do on a read. This is because the specification does not provide for the ability for a container to know if a bean is "dirty" or not, and so it must assume that any bean must be rewritten back to the database.
However, as you know, this is not necessarily true. Therefore, WebSphere 4.0 allows you to specify the "Access Intent" of the "getter" fields to be either "read-only" or "update". By default, the value is "update". You change this value in the AAT -- it must be done for all the getter fields in your EJB.
If WebSphere detects that an EJB in a transaction has only had "read-only" methods called, it does not write it back (call ejbStore) at the end of the transaction.
Kyle