Differences between stateless Session Bean and stateful Session Bean and instance pool

 

1. What is the difference between stateful Session Bean and stateless Session Bean? From the aspect of writing: there is no difference between interfaces. The Bean class uses stateless and statefull. From the client side: there is no difference. In terms of containers: For stateless session beans, when a client sends a request, instances may not be created, so multiple clients may share the instance, the information stored by the instance member variables is not stored for a specific customer. The information is shared by all clients and is somewhat similar to the static members of Java. The client cannot expect the server to save the information for you. The information required for processing is passed through the parameters of the method. If there is a stateful Session Bean, the server creates an independent instance for each client (to save the information), and the information of each client is saved by the corresponding instance, information can be shared between multiple client method calls (initialize, addbook, and removebook). Each method call only needs to pass additional information. 2. the application in the instance pool reduces the time it takes to create and release instances through instance sharing, thus improving the performance. As an enterprise-level application, there are many times of creation and release. The server can create several bean instances in advance. When a client accesses the instance, it can quickly allocate an instance to the client and then put it back after it is used up. For stateless session beans, you can select any instance from the instance pool when a request occurs. For stateful session beans: if a new request has an idle instance (not associated with the client), select an idle instance from the instance pool. If no idle instance exists, find the instance associated with the client (assumed as C2) but not used. First, save the status information for C2 (suspend C2 or deactivate C2). If there is no idle instance, if no client can be suspended, wait. if it is not a new request (which can be considered a second or later method call), First find whether the instance associated with it exists. If it is present, call the method directly; if the associated instance is unavailable, find the idle instance and use the information saved by the server for the current customer to initialize the instance (activation). If no idle instance is available, first suspend another customer and then activate the current customer. If no idle instance or client can be suspended, wait for. Li xucheng csdn blog: Login? U= 124362 & C = 7be8ba2b6f3b6cc5