• 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 Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

question #8 p293

 
Greenhorn
Posts: 23
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I'm alittle confused on the naming convention in this question
entity beans - refers to the actual row in the database not the bean pulled from the bean pool to play the role of the particular entity
entity object - refers to the object ref not the bean pulled from the bean pool to play the role of the particular entity
Am I right?
 
Greenhorn
Posts: 29
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hope this helps...
1)Entity is the row in the DB.
2)Entity Bean is the Object Oriented EJB view of that Entity in the DB.
3)EJBObject is the container created refrence to the Bean. It is not specific to any bean in the pool, rather it is created only after:
a)The container picks one bean from the pool and call the ejbCreate() method on it in response to the create() called by the Client on the Home interface.
b)The client calls a findXXX() method and the container either locates an existing EJBObject or creates one for the client based on the Primary Key passed by the Client.
 
Ranch Hand
Posts: 275
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Concerning the terminology, the spec page 113 says An entity bean�s remote home interface defines one or more finder methods, one for each way to find an entity object or collection of entity objects within the home. So since we know that finder methods return references to the component interface, we can say with impunity that the term "entity object" is the same as "component interface for an entity bean". This agrees with "D" not being checked because if "entity object" meant "entity bean", then it WOULD be true that we couldn't give out a reference to it.
I'm still puzzled about "A" being checked, though. I know I read somewhere* (in HFE) that an exception would be thrown if two clients tried to run the same method at the same time. But the spec p 108 where the question was pulled from makes it sound like that will never happen. I STILL think as the client you need to worry about catching exceptions because someone else has a hold of the data you want. True?
--Dale--
Edit: Why is it the solution comes to me only after I post? I think I see what the problem is, and it goes back to the terminology. Yes, you'll get exceptions if two clients work on the same "entity bean" at the same time, but now I recall that the container WILL smooth-over situations with respect to methods on the component interface to the bean (aka entity object). So maybe what this "A" thing means is that you don't need to catch exceptions with things that come from EJBObject?
[ April 17, 2004: Message edited by: Dale Seng ]
 
Ranch Hand
Posts: 1683
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Multiple clients can access an entity object concurrently if they had obatined the same EJB Object stub.
As to what happens with more than one business methods being invoked at the same time: the Container handles that by synchronization of the bean with the DB. When the EJB Object has a business method called, say setAddress(), the Container will start a transaction, tell the DB to lock the row, and load the bean. At the end of the transaction, the Container will commit (or rollback) and tell the DB to release the lock on the row.
Whilst all this is happening, another setAddress() method call will just have to wait.
 
Tomorrow is the first day of the new metric calendar. Comfort me tiny ad:
a bit of art, as a gift, that will fit in a stocking
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic