Temporarily turn off the sync triggered by the findXXX?

[henrichen]

Is there a way to turn off the automatic sync (calling ejbStore()) triggered by findXXX()?

I know this is for the spec compliance but this behavior does give me some trouble. I am thinking if there is some kind of API that I can temporarily turn this behavior off.

Anyone knows how I can do that? Thanks in advance.

Henri

[davidjencks]

You can't turn it off. Why is it a problem? in jboss 3 if you mark your beans read only in jboss.xml ejbstore will not be called on them. (if they are cmp2 and marked read-only in jbosscmp-jdbc.xml you also won't be able to change their values). With cmp2 in any case unchanged entities will not result in db access when ejbstore is called.

[henrichen]

David,

Thanks for the reply.

My senario is like this: (maybe you can give me some suggestions)

1. I implement in EJB X's ejbStore() a data validation code. The validation would check whether the two fields of X to be consistent to each other.

2. The data of the second field comes indirectly from another EJB Y.

3. The session bean Z calls the field1 setter of X to update field1, then calling findByName() to get EJB Y (The Y's name is input by user) and get the value from Y and update field2 of X.

4. The trouble is when the findByName() is called on step3, the ebjStore() is called earlier then expected (well, in some sense). And the validation code would complain the validation fail because the field1 has been updated while the field2 has not, yet.

Of course, I can just reverse the updating of the field1 and field2 but I think that is too tricky and error prone. What if we have another field which also needs findXXX() to do some data retrieving?

Or I simply should not put validation code in ejbStore(), there is another better place?

Henri

[davidjencks]

I think you should put the data validation code in the session bean. Even if you got it to work in entity X (anywhere, not just ejbStore) there is nothing to prevent someone from changing Y to make X no longer valid. If all access to both X and Y is through a session bean, then that session bean can always check the consistency conditions before committing.