EJB2.0 Remote and Local Interfaces

[Kodo Tan]

Hi all
Suppose there are 2 EJB clients accessing the entity bean pointing to the SAME physical row in database with one using local interface and the other, remote interface.
Will there be a single entity bean instance or 2 instances ?
Thanks in advance

[Tim Holloway]

You're making a common mistake. entity EJBs are NOT objects representing rows in a database table -- they are objects in their own right, uniquely identified by their primary keys. To have a row in a database table serve as the backing store for an EJB is common, but not essential, and, in fact, for coarse-grained EJBs, the actual backing store may be multiple rows.
So when you attach to an EJB for a given primary key, it doesn't matter what interface you reference it by, it's still the same EJB.

[Phil Sharp]

Kodo
As Tim states the persistence mechanism and the fact that it is local or remote interfaces does not matter.
I think you are trying to ask about concurrency.
For Session beans both Stateful and sateless its not an issue as they are logically specific to a session (note the implementation may be sharing instances but the client is not effected by this).
For entity beans the story is a little more complicated. There is only one entity bean instance for a specific entity defined by its primary key. However multiple clients can be connected to it through the EJB Object.
EJB solves the problem of concurrency by prohibiting concurrent access to bean instances. Therefore even though multiple clients can be connected to the EJB object only one can invoke methods on the entity bean instance. Any other client has to wait until a method invocation is complete. In fact the scope is larger in that a bean cannot be accessed by anything outside the current transactional context until the transaction is completed.
This is described better in Enterprise JavaBeans by Richard Monson-Haefel. A very useful resource (alongside Mastering EJBs by Ed Roman).
Some implementations such as WLS have additional functionality to improve performance - read-only beans etc. to cause further confusion - you need to review your application servers documentation for further information.
Phil

[Kodo Tan]

quote:
You're making a common mistake. entity EJBs are NOT objects representing rows in a database table -- they are objects in their own right, uniquely identified by their primary keys. To have a row in a database table serve as the backing store for an EJB is common, but not essential, and, in fact, for coarse-grained EJBs, the actual backing store may be multiple rows.
I know about this - did I say entity EJBs must be respresenting a row in db in my posting ?
quote
So when you attach to an EJB for a given primary key, it doesn't matter what interface you reference it by, it's still the same EJB.
I just want to know how many bean instances under certain scenarios

[Tim Holloway]

OK, back to what I said earlier. Because EJBs are independent objects in their own right, any relationship(s) between an EJB and a row (or rows) in a database is whatever you (and your EJB container) define.
It is possible to design multiple EJBs that reference the same table row, but in practical terms, about all that would gain you would be trouble, since the EJB container is expected to manage EJBs, not whatever persistent storage system you're using. BMPs are dangerous because the only DBMS consistency logic will be whatever you code yourself, but CMPs are perhaps even more treacherous, since there's nothing in the EJB specs to address this and they can therefore be expected to behave unpredicatably from the DBMS's point of view.
If you gain 2 references to an EJB and they both return the same Primary Key, they ARE the same EJB, regardless of what type of interface you're using and INDEPENDENT of what -- IF ANY -- DBMS or other data persistency mechanism is backing the EJB.