Hello All,

In some of the discussions, I found that it was recommended that while doing updates/deletes that affect multiple rows in the data base, we must not use entity beans since many beans would be loaded and each information pertaining to each row would be stored independantly. Obviously this would make the system slow and an efficient manner is to fire these updates/deletes from a session bean.

The question is that if the system is using BMP entity beans for some other operations and the corresponding row is updated by the session bean, how would the entity bean be informed.

I dont see any way by which the entity bean could be informed by the container but I am looking for some tried and tested work arounds ?

Thanx a lot
Jeetendra

Hi,

You should use commit option B or C instead of A. commit options are specified by the ejb1.1 specification. A means that there is no other process/bean/application accessing and modifying the data (which is a very naive assumption) with B and C (i can't tell you the difference from the tp of my head, look it up) the Entity bean verifies it's data integrity with the database.. so that's your solution..

cheers,

Joost.

Hey there.
The note about using commit options B and C is crucial, but it doesn't answer your question. Btw:, the difference between B and C is pretty academic, but if you're interested:
Commit option B: the container keeps a cached instance of an entity between transaction, but does not assure it total control so it must synchronize it when beginning/committing a transaction.
Commit option C: the container doesn't keep a cached instance of an entity. It returns instances to the pool as soon as their transaction is concluded.

To find out which commit options your App server supports check out it's docs.

As for your question, the App server does not notify the entity beans of such deletion. If the entity was deleted and a bean tries to select it, it simply won't find it and should throw NoSuchEntityException. If the entity beans has selected the row, then it was deleted, and then it tries to update it it either won't find it (handle same way as above), or the DB will not allow it to update (can occur with optimistic locking like with Oracle SERIALIZABLE transactions). In either case, you will get some sort of indication from the DB about the problem.
Note that this holds only for BMP beans. In general, your client should expect a java.rmi.NoSuchObjectException.

Gal