Enterprise JavaBeans
by Richard Monson-Haefel

Unconfirmed error reports are from readers. They have not yet been 
approved or disproved by the author or editor and represent solely
the opinion of the reader.


This page was updated August 22, 2002. 


Here's a key to the markup:

        [page-number]: serious technical mistake
        {page-number}: minor technical mistake
        <page-number>: important language/formatting problem
        (page-number): language change or minor formatting problem
        ?page-number?: reader question or request for clarification


UNCONFIRMED errors and comments from readers:


{Chapter 3} This question regards the concurrency control:

I have read that "Serveral Clients can connect to EJBObject but only one client
can access the Bean instance" (Chapter 3: Concurrency ).

I am afraid I have not understood this properly. Because, suppose the EJB
server vendor implements such a way that there is one EJBObject per client.
If two clients are talking to the server and are requesting for a ship entity
bean with say id = 4, how can the container manage concurrency?? Because 
each of the EJBObjects for these two clients are given a separated bean 
instance by the container.


(63) Line 4 now reads:
 
	"to more then one table."

It should read:
	
	"to more than one table."


(64) The last paragraph on page reads:

"Its tight integration with Java makes it an idea choice for Java-only 
systems."

It should read:

"Its tight integration with Java makes it an ideal choice for Java-only 
systems."


(69) The fourth paragraph reads:

"Java RMI and CORBA uses their own naming services."

It should read:

"Java RMI and CORBA use their own naming services." 


{147}  The third line from the bottom reads:

	"such as ejbload() and ejbsave()"

It should read:

	"such as ejbload() and ejbstore()"


{160}  code fragment;
The errata to the code fragment on page 151 also applies to the code 
fragment on this page (being a discussion of the complete class given earlier). 

{162}  The second paragraph reads:

public interface ShipHome extends javax.ejb.EJBHOME{
       public Ship findByPrimaryKey(ShipPK PrimaryKey)

It should read:

public interface ShipHome extends javax.ejb.EJBHOME{
       public ShipPK findByPrimaryKey(ShipPK PrimaryKey)


[162] In the fourth paragraph, it now reads:

	public class ShipBean extends javax.ejb.EntityContext

should read:

	public class ShipBean implements javax.ejb.EntityContext


{165}  In the first full paragraph, third sentence, you say that a find 
method that returns a single primary key (the default find is a good example) 
returns the bean interface which serviced the find method.

This is in conflict with the EJB 1.0 and 1.1 specification.  The 
specification says:

	"The instance is in the pooled state ... when the 
	container selects the instance to execute the ejbFind<METHOD> 
	method on it, and is RETURNED TO THE POOLED STATE when the 
	execution of the ejbFind<METHOD> method completes." (EJB 1.0 spec,
	 page 65-66)

(Note this is also true in the 1.1 spec)

Therefore, if one were following the specification, the bean that runs the 
find method may or may not become the "ready state" bean.

The code still works as written, it just seems that an unnecessary DB 
access may occur.  This might result in performance issues where one bean 
services the find request, and another becomes the "ready state" bean for 
that Primary Key. 


(190)  use of the word 'nontransient';
Recommend using a word other than 'nontransient' when explaining the 
SessionContext reference may be stored in a 'longer lived' instance 
field of the stateless session bean.  

The 'transient' keyword in java turns off serialization for a field, 
so the word 'nontransient' can be initially interpreted to mean a field 
with serialization.  This is really confusing until it is understood 
that 'nontransient' in the statement really means 'non short-term'.

Page 214 has the same problem.


{207}  listAvailableCabins method;
Very minor issue in June 1999 printing/First edition of this book:

A bedCount is passed to this method, but is never used.  It would make 
sense to do either of the following:

1) Use this method to list all available cabins, no matter the bed count.  
The following modifications would then be needed: Do not pass a parameter 
to this method and include BED_COUNT in select statement (i.e. select ID, 
NAME, DECK_LEVEL, BED_COUNT...) and the reading of the result 
(i.e. buf.append(result.getString(4))...).

2) Use this method to list all available cabins with the provided bed 
count.  The following modifications would then be needed: Modify where 
clause to include BED_COUNT (i.e. and BED_COUNT = ?...) and add another 
setInt for the prepared statement (i.e. ps.setInt(3, bedCount)...).   


?209? There are characters like "212" at the end of first paragraph
under the section "Why are we accessing ............. Reservation bean?"


(271) The first paragraph after the code reads: 

"The disadvantage is that the bean must frequently de-reference the
ship's primary key..."

It should read:

"re-reference the ship's primary key..." 


?295? Under Appendix B, Sequence diagram for Container - Managed 
persistence.  Here the business method on EJBObject is shown to 
have invoked on the container. I think it should be invoked on 
the Bean instance.