As per my understanding the multiple instances of the same entity are
serving the concurrent clients and the multiple access to the same row
in the database concurrently can lead to the data corruption,this issue has been tackled by the Containers transaction manager.
Assume the first user generating the bean for the row a,the ejbLoad()
does get the data from the database,considering his work not ended with the instance the other client tries to use the same row again the
ejbLoad() will come in picture and load again the values from the database corresponding to the row a.Now both are in the CACHE(in-memory) of the Server and we can do the manuplation in the dat a view of the row a,which will be very fast.
Now if the first instance invoke the method from the bean and some of the instance variable gets changed,and the bean is not doing any work,does the ejbStore come in the picture,OR IT DOES COME IN PICTURE
ONCE THE ENTIRE INSTANCE HAS DONE WORK.
I'm not sure I understand exactly what your question is (the last paragraph is somewaht unclear), but I will try to answer what I think you mean. I assume your question was "when is ejbStore called?".
The "theoretic" answer to this question is that you can't tell. The App server might invoke the ejbStore at occasions as a part of it's persistence algorithm, with hardly any bounds placed on it by the spec. Basically, you can expect ejbStore to be called at the end of a transaction except when using proprietary modes like "read only transactions".
However, it is a common mistake to assume that this is the only time ejbStore is called. Many people say "yeah, the container 'could' call it but it won't". Actually, there are cases where the container *must* call ejbStore in the middle of a transaction. One example is when a finder method on an entity bean which is loaded at the same transaction context is called. The container must call ejbStore on the loaded entity so the finder's SQL query will see updates to the entity's row.