question #8 p293

[Van Nguyen]

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?

[Rajnish Bhasin]

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.

[Dale Seng]

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 ]

[Roger Chung-Wee]

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.