Win a copy of Murach's Python Programming this week in the Jython/Python forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

ejbStore and DB2 Update triggers  RSS feed

 
Sean Erwin
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Sorry
running Websphere 4.01 on OS/390 with db2 7.1 on os/390
Thanks
Sean
 
Kyle Brown
author
Ranch Hand
Posts: 3892
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Kyle we are using a session facade patter so access is wrapped in a session bean
 
Kyle Brown
author
Ranch Hand
Posts: 3892
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!