Going thru the description of entity beans I understood that there exists only one remote object & bean instance for a particular data entity (eg. customer #28) across multiple clients. This wud consequently mean that the Remote EJBObject is multithreaded... am I right in this assumption? Best Regards, Anand.
Good Question :-) But as i think (logically)the ejbObjects are not multithreaded rather request comming from multiple client are cued. because while one client is working on an entity, that entity is locked. Thus no other client can access that particular entity. So there is no use of keeping the ejbObject Multithreaded. Any comments from any one?
If we think about this, if the entity bean was multi-threaded, that would indicate that there is virtually multiple entity objects. That is fine, except as has been mentioned, the database is locked when the entity bean is altering it, so in essence, the number of virtual objects would be queued waiting for the lock to be release so the next one could have a go. This would be the same as having one entity bean that everyone is utilising, and locking the particular times when it is altering the database. So many people can have a reference to the one entity bean, however, the entity bean will only alter the database for one at a time. Remembering that before it alters the database it will run the ejbLoad() method first followed by the database alteration followed by the ejbStore() method. So in answer to your question, the entity bean is not multi-threaded, but instead the container synchronises the parts where it has to alter the database, and correspondingly, locks the database during the modifications. Hope this helps Best Regards Matt Gaunt
According to Ed Roman et al in "Mastering Enterprise JavaBeans", it is highly likely that there are multiple bean instances for the same entity, each bean instance servicing a particular client request in a single-threaded way. I've always tended to think of entities as being singleton-like critters - there is only one and you either have it or you don't have it. Ed's description says that isn't the case. Makes sense from a performance standpoint - queuing up on a high-demand bean would be undesirable. Also makes sense from a clustering standpoint - a cluster wouldn't be much good if you had to funnel all your entity requests through one member of the cluster just to get at a particular entity bean.
Reid - SCJP2 (April 2002)
He's my best friend. Not yours. Mine. You can have this tiny ad:
Devious Experiments for a Truly Passive Greenhouse!