• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Paul Clapham
  • Jeanne Boyarsky
  • Junilu Lacar
  • Henry Wong
Sheriffs:
  • Ron McLeod
  • Devaka Cooray
  • Tim Cooke
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Frits Walraven
  • Tim Holloway
  • Carey Brown
Bartenders:
  • Piet Souris
  • salvin francis
  • fred rosenberger

Are Remote objects multithreaded?

 
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.
 
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?
 
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
 
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.
 
He's my best friend. Not yours. Mine. You can have this tiny ad:
Devious Experiments for a Truly Passive Greenhouse!
https://www.kickstarter.com/projects/paulwheaton/greenhouse-1
    Bookmark Topic Watch Topic
  • New Topic