ChinMing Kuo wrote:
I think we should be clear here to make sure we are talking about the same thing. I believe what you are referring to here is entity object identity.
The part that gets me is that I�ve seen references (in both books and here) of the same entity bean (of, say record A) can have multiple instances (all are record A, not record A, B, C, etc) referenced by multiple clients. But I have seen no examples of such to illustrate the scenarios where having multiple instances of the same bean are desirable.
Every entity object has a unique identity within its home. If two entity objects have the same home and the same primary key, they are considered identical.
What can happen is that two objects may be identical but the container may delegate the method calls to two different bean instances.
So for example in the following code snippet:
Account a1 = accountHome.findByPrimaryKey(1);
Account a2 = accountHome.findByPrimaryKey(1);
a1 and a2 are considered to be the same object. However the container may delegate calls on a1 to a different bean instance then calls to a2.
I believe you may be asking why the container might do that and I believe the answer would be for improved run time performance. Imagine for example that a1 and a2 are used in different threads. If the same instance is used the container would have to serialize the calls. (Why? Because the bean instance is not thread safe.) This would be a bottleneck if the same instance is accessed by multiple clients or threads.
The next question is what are the implications of having calls to what is essentially the same object being handled by two different bean instances? What prevents things from going out of whack? I believe the answer to that is transactions. Each method call occurs in a separate transaction.
So lets take an example. Suppose that the Account class has an increment(int x) method. Assume also that the Account bean has a private member variable balance. How should that be implemented in the bean? There are 2 possibilities.
1) public void increment(int x) {balance += x;};
2) public void increment(int x) { //use jdbc to increment the balance in the db using sql like "update account_table set balance = balance + ? where account_key = ?". The first question mark is set to x and the second question mark is set to the primary key of the bean.}
Rather than give you my answer let's take a vote. Please send in your response to this list with your explanation.
Answers are.
a) Must be 1.
b) Must use 2.
c) Can use either but 1 is always better.
d) Can use either but 2 is always better.
e) Either one is OK depending on the circumstances.
f) Neither one is correct.
I look forward to your answers.
Dan
I can think of the reason where single instance can be a synchronization bottleneck, but what�s the proper programming model for multiple instances of the same bean? Shall I think of it the same OODB terms and assume every client is holding the only copy in memory and it�s ALWAYS the same as the one on disk, and let the container worries about maintaining consistence among all the instances of the same bean?
Is this flexibility in EJB (compared to OODB or persistent Java) purely for performance optimization?===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
