Understanding of ejb3 stateless and stateful

 

Stateful or stateless is understood and used together with the user, that is, whether the status is relative to the user, such as the following code:

 

Package cn.edu. USTC. ejbs. impl;

 

Import javax. EJB. Remote;

Import javax. EJB. stateless;

 

Import cn.edu. USTC. ejbs. statelessejb;

 

 

@ Stateless (mappedname = "statelessejbimpl ")

@ Remote

Public class statelessejbimpl implements statelessejb {// defines a stateless Session Bean

Private int value = 0;

 

Public void sayhello (INT value ){

System. Out. println ("Hello, your value is:" + value );

System. Out. println ("your last value is:" + this. value );

This. value = value;

}

 

}

 

 

 

Package cn.edu. USTC. ejbs. impl;

 

Import javax. EJB. Remote;

Import javax. EJB. stateful;

 

Import cn.edu. USTC. ejbs. statefulejb;

 

 

@ Stateful (mappedname = "statefulejbimpl ")

@ Remote

Public class statefulejbimpl implements statefulejb {// defines a stateful Session Bean

Private int value = 0;

 

Public void sayhello (INT value ){

System. Out. println ("Hello, your value is:" + value );

System. Out. println ("your last value is:" + this. value );

This. value = value;

}

 

}

 

 

Client (User) code:

 

 

Initialcontext CTX = new initialcontext ();

Statelessejb hello0 = (statelessejb) CTX. Lookup ("statelessejbimpl # cn.edu. USTC. ejbs. statelessejb ");

Hello0.sayhello (1 );

Hello0.sayhello (2 );

Statelessejb hello1 = (statelessejb) CTX. Lookup ("statelessejbimpl # cn.edu. USTC. ejbs. statelessejb ");

Hello1.sayhello (1 );

Hello1.sayhello (2 );

 

Statefulejb hello2 = (statefulejb) CTX. Lookup ("statefulejbimpl # cn.edu. USTC. ejbs. statefulejb ");

Hello2.sayhello (1 );

Hello2.sayhello (2 );

Statefulejb hello3 = (statefulejb) CTX. Lookup ("statefulejbimpl # cn.edu. USTC. ejbs. statefulejb ");

Hello3.sayhello (1 );

Hello3.sayhello (2 );

 

 

The output result is as follows:

 

 

 

Hello, your value is: 1

Your last value is: 2

Hello, your value is: 2

Your last value is: 1

--

Hello, your value is: 1

Your last value is: 2

Hello, your value is: 2

Your last value is: 1

--------

Hello, your value is: 1

Your last value is: 0

Hello, your value is: 2

Your last value is: 1

--

Hello, your value is: 1

Your last value is: 0

Hello, your value is: 2

Your last value is: 1

 

 

It can be seen that stateful session beans will save the last access status when accessed by instances of the same class. hello2 and hello3 are two different instances, the container will generate a unique Session Bean for this instance for different instances, so the result of calling sayhello is the same. The value of the State (I) of the stateless Session Bean is meaningless, and the value of I is changed no matter which instance is accessed.

 

 

 

 

Let's take a look at their definition:

Stateful Session Bean: each user has its own unique instance. During the user's lifetime, bean maintains user information, that is, "stateful "; once the user dies (the call ends or the instance ends), the life cycle of the bean ends. That is, each user will initially get an initial bean.

 

Stateless Session Bean: Once instantiated, the bean is added to the session pool, which can be shared by all users. Even if the user has been extinct, the bean life cycle may not end, and it may still exist in the session pool for other users to call. Because there is no specific user, the status of a user cannot be maintained, so it is called stateless bean. However, the stateless Session Bean is not stateless. If it has its own attributes (variables), these variables will be affected by all users who call it, this must be noted in practical applications.

 

That is, the existence of status cannot be distinguished by bean attributes or other factors. stateful or stateless is not for the status (member variable or attribute) in the Session Bean ).

 

For stateful session beans, as long as a client sends access to a stateful Session Bean, the server creates a session bean instance that corresponds to the client, in this way, the instance corresponds to the client one by one. If the client saves the information in the bean instance, it can be used later.

 

For stateless session beans, the server maintains an instance pool and creates several instance objects for the client to call. When sending a request to create a session bean from a client, it is not always necessary to create an EJB. In most cases, an instance is obtained from the instance pool, and then the instance pool is put back after use. If you try again next time and then retrieve an instance from the instance pool for use, it is not necessarily the last instance. Even if the two accesses use the same instance, other clients may access the instance between the two accesses. Therefore, there is no guarantee that the information will be saved between multiple accesses. Therefore, stateless session beans do not specifically save or unnecessary client information. Is it necessary to create an instance pool? Spring's Singleton bean can also meet each request of different users. With the current knowledge, I personally think that there is no need for synchronization in the Session Bean method, and there is no need to maintain an instance pool. I just learned that ejb3.1 indeed added the singleton Session Bean. In my test example, the stateless bean seems to be the same instance every time, so that the value in the last access will be obtained for the subsequent accesses, just like Singleton.

 

As for stateful and stateless performance, a session bean needs to save the information of a specific client. A client corresponds to an instance, which is not only when the client has a connection and no access, you also need to keep this instance for this client. In this way, as the number of clients increases, the number of instances to be created on the server also increases. Increasing to a certain extent will affect the server performance. In order not to affect the server performance, the server is usually optimized. When the number of clients exceeds a value, no new instance is created. Even if you do not create a new instance, you still need to respond to the user. In this case, you can share the instance. It will check which instance is in the connection status but is not accessed, and then save the instance status and use this instance as the new request service. For the original client, it is called a suspension. If the original client sends a request again, it searches for an idle instance again and restores the saved status. This process is called activation. Therefore, in the access process of stateful session beans, operations such as instance search and activation suspension often occur, so the efficiency is relatively low. When sending a request to the stateless Session Bean, you can take an idle instance as the client service, so the efficiency is relatively high.

 

The advantage of stateful Session Bean is that it can save the status of the client, so the client can transmit less parameters during subsequent access. The stateless Session Bean needs to pass all the parameters required during method execution.

 

We can determine the advantages and disadvantages of stateful Session Bean and stateless session bean analyzed above. If frequent access is required and some information is shared among multiple accesses, a stateful Session Bean should be used. For infrequently used functions, you can use stateless session beans. Stateless session beans are used more than stateful session beans.