Packages
javax.naming	Provides the classes and interfaces for accessing naming services.
javax.naming.directory	Extends the javax.naming package to provide functionality for accessing directory services.
javax.naming.event	Provides support for event notification when accessing naming and directory services.
javax.naming.ldap	Provides support for LDAPv3 extended operations and controls.
javax.naming.spi	Provides the means for dynamically plugging in support for accessing naming and directory services through the javax.naming and related packages.(Service Provider Interface)

                     Atom / Consistency / Isolation / Durability
                                         
                     4 Isolation Levels: Read uncommitted / Read Committed / Repeatable Read / Serializable         

  

Step1: Definition of Remote Interface
              public interface Count extends EJBObject{
                        public int count() throws RomoteException;
                      }
Step2: Definition of Home Interface
               public interface CountHome extends EJBHome {
                        Count create(int val) throws RemoteException, CreateException;
                      }
Step3: Definition of Bean Class
               Public class CountBean implements SessionBeam {
                          public int val;
                           public int count() {
                              System.out.println("count()");
                              return ++val;
                              }
               public void ejbCreate(int val) throws CreateException {
                            this.val=val;
                            System.out.println("ejbCreate()");
                         }
                 public void ejbRemove(){};
                 public void ejbActivate(){};
                 public void ejbPassivate(){};
                 public void setSessionContext(SessionContext ctx){};
          }

Step4: Definition of ejb-jar.xml

                   <ejb-jar>
                      <enterprise-beans>
                        <session>
                           <ejb-name>Count</ejb-name>
                            <home>CountHome</home>
                            <remote>Count</remote>
                            <ejb-class>CountBean</ejb-class>
                            <session-type>Stateful</session-type>
                            <transaction-type>Container</transaction-type>
                        </session>
                      </enterprise-beans>
                    </ejb-jar>                    

        

     摘要:   阅读全文

--) Life Cycle of a Stateful Session Bean

The following figure shows the life cycle of a stateful session bean. It has the following states:

• Does not exist. In this state, the bean instance simply does not exist.
• Ready state. A bean instance in the ready state is tied to particular client and engaged in a conversation.
• Passive state. A bean instance in the passive state is passivated to conserve resource.

The various state transitions as well as the methods available during the various states are discussed below.

--) Life Cycle of an Entity Bean

--) Dirty Read? 
Dirty reads occur when transactions are allowed to see uncommitted changes to the data. In other words, changes made inside a transaction are visible outside the transactionbefore it is committed. If the changes are rolled back instead of being committed, it is possible for other transactions to have done work based on incorrect, transient data.

--) Nonrepeatable reads occur when:
 a) Transaction A reads a row

 b)Transaction B changes the row

 c)Transaction A reads the same row a second time and gets different results

--) Phantom reads occur when:  
a)Transaction A reads all rows that satisfy a WHERE condition   
b)Transaction B inserts an additional row that satisfies the same condition   
c)Transaction A reevaluates the WHERE condition and picks up the additional phantom row

--) READ_UNCOMMITTED?
By setting the isolation level to you are saying that you won't have a problem with reading data that might get rolled back. If this is unacceptable, use a more restrictive isolation level.

--) What is the default transaction isolation level ?
A. READ_UNCOMMITTED
B. READ_COMMITTED
C. REPEATABLE_READ
D. SERIALIZABLE
E. None of Above

Note:The Isolation level depends on the database in use.

1. TRANSACTION_READ_UNCOMMITTED - allows transactions to see uncommitted changes to the data. This means that dirty reads, nonrepeatable reads, and phantom reads are possible.
2. TRANSACTION_READ_COMMITTED - means that any changes made inside a transaction are not visible outside the transaction until the transaction is committed. This prevents dirty reads, but nonrepeatable reads and phantom reads are still possible.
3. TRANSACTION_REPEATABLE_READ - disallows dirty reads and nonrepeatable reads. Phantom read are still possible.
4. TRANSACTION_SERIALIZABLE - specifies that dirty reads, nonrepeatable reads, and phantom reads are prevented.

Q: Can you give me a use example of  Java Reflection?
A: I will use Reflection to analyze an original Java class given as input to find out which method signatures the class provides.
Q: Jsp declaration do not have access to implicit variables like request, response, page, pagecontext, out, session, application, config, exception. True or False?
A: True