Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Are Remote objects multithreaded?

 
Anand Edwin
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Rajeev Gupta
Greenhorn
Posts: 16
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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?
 
Matt Gaunt
Ranch Hand
Posts: 34
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
Reid M. Pinchback
Ranch Hand
Posts: 775
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic