Status Session Bean

1.Stateless sessionBean
Literally, a stateless Session Bean is a bean that cannot identify its current state attributes. For example:
Public Class {
Public (){}
Public String Hello (){
Return "Hello who? ";
}
}

Public class client {
Public client (){
A A = new ();
System. Out. println (A. Hello ());
A B = new ();
System. Out. println (B. Hello ());
}
}
Two instances of a are generated in the client. No matter the object A or B, they are stateless. For client, there is no difference between A and B (but! = B ). Therefore, instances of the same stateless Session Bean are the same and can be reused by different clients.

2.Status sessionBean
As for the State Session Bean, we can understand it as follows: it has the storage capability. That is to say, there must be at least one attribute to identify its current status. For example:
Public Class B {
Private string name;
Public B (string Arg ){
This. Name = ARG;
}
Public String Hello (){
Return "hello" + this. Name;
}
}

Public class client {
Public client (){
B A = new B ("China ");
System. Out. println (A. Hello ());
B = new B ("world ");
System. Out. println (B. Hello ());
}
}

3.Scheduling pool:
In fact, the concept of the scheduling pool is basically the same as that of the data connection pool, which is designed to improve system performance. Just like a dumpling restaurant, there are two kinds of dumplings. One is to drop some dumplings and wait for the guests to get them out immediately. Another way is to drop the dumplings after the guests come. This example is obviously not very appropriate, but it does illustrate the problem. The concept of a scheduling pool is like the first practice of dumplings. Some bean instances are first put into the pool (that is, cached. The specific cache size depends on different containers) it can be used directly when called by the client. The difference between it and dumplings is still very big. If there are no guests to eat them after the dumplings are down, it would be terrible.

4.Stateless sessionBeanImplement scheduling pool scheduling:
The stateless session bean does not save the session state, so no matter which client calls a stateless Session Bean, there is no difference, that is to say, any stateless Session Bean instance can provide services for the client program. In addition, the relationship between the stateless Session Bean and the client is 1: N. That is to say, the same session bean instance can be used by different clients. Therefore, stateless session beans can be stored in the scheduling pool for reuse by different clients.

5.Status sessionBeanImplement scheduling pool scheduling:
The State Session Bean maintains the state of the current session, which is far more difficult to implement than the state Session Bean. Because it needs to save the session status, but the physical memory space is limited, it is impossible to save the current session Status of N multiple clients. The EJB container adopts the same practice as the operating system to save the state Session Bean conversation status in the hard disk or other storage (PassivationPassivation). When the original client calls the method of the passive bean, the passive state is returned to the bean (ActivateActivation). Maybe the container returns the passive state to different bean instances. What is the relationship? As long as the bean instance can be exactly the same as the bean instance that was previously deactivated. In fact, it is exactly the same: Most containers use the least recently used (Least recently used: LRU. Because it is impossible for the client to perform operations all the time, it may be reading news or something. So it is very reasonable and effective to deactivate bean in this way.But there is one exception: the transaction is being processedBeanYou must wait until the transaction is processed.Most containers are activated as needed (Just-in-time. The customer has a request. OK is OK. Activate the passive bean :)Note: inactive and inactive sessionsBeanIt doesn't matter.

6.Rules for dialog State compliance:
Bean complies with Java object serialization rules (Java object serialization ). Because the javax. EJB. iseisebean interface extends the java. Io. serializable interface, every enterprise Bean class indirectly implements this interface.

7.Status sessionBeanThe content stored during passivation is as follows:
A. EJB object reference.
B. Home object reference.
D. Reference of the EJB context.
E. JNDI naming context.

8.Callback Method for activation and passivation:
Each session bean implements sessionbean, so each session bean has the ejbpassivate () and ejbactivate () methods. The EJB container calls the ejbpassivate () method to release or process the resources occupied. Call the ejbactivate () method to restore the bean to the resources released during ejbpassivate.