前段时间纠结过一个问题，就是为什么无状态会话bean需要一个组件池来存放多个实例。
在我看来，无状态会话bean提供的是一个业务逻辑，它并没有保存任何的状态信息，那么，也就是说对于同一个bean的两次调用并没有什么不同，那为什么不能在服务端只维护一个bean的实例呢，就像servlet一样。
经过一段时间的探究，终于在网上找到了答案（还是国外的网站比较给力）：
Some of the reasons why I think a pool of stateless session beans is necessary (the excerpts referred below are from the O�reilly EJB book):
1)�Beans that are involved in transactions are subjected to the isolated ACID property, which means that their services cannot be shared during the life of the transaction.� [O�reilly EJB book]. If my interpretation of �services cannot be shared� is correct, then that means no other client can access the same method of the stateless session bean already involved in a transaction. Hence just having one instance of a stateless session bean will be a bottleneck if it is involved in a transaction.
2)�When a system exception occurs, the bean instance is discarded, which means that it's dereferenced and garbage collected. The container assumes that the bean instance may have corrupt variables or otherwise be unstable, and is therefore unsafe to use. The impact of discarding a bean instance depends on the bean's type. In the case of stateless session beans and entity beans, the client does not notice that the instance was discarded. These types of beans are not dedicated to a particular client; they are swapped in and out of an instance pool, so any instance can service a new request.� [O�reilly EJB book]. Hence having only one instance of a stateless bean can impact the availability of the service it offers in case a system exception occurs in one of its methods while serving a client request.
3)�If, however, the session bean is managing database data for the user, it may want to know about the beginning and ending of user transactions, so that it can cache data at the start and commit its database updates at the end. For this reason, the EJB specification allows session beans to optionally implement the javax.ejb.SessionSynchronization interface. By implementing this interface, the session bean indicates that it wants the container to notify it about the beginning and end of transactions.� [O�reilly EJB book]. This is related to point no. 1) above � �Session beans involved in transaction�. Though use of SessionSynchronization may make more sense for a stateful session bean, it is still available for stateless beans. Hence I am not sure how only one instance of a stateless session bean serving many clients can handle SessionSynchronization in a transaction.
4)�The SessionBean.setSessionContext(SessionContextcontext) method is invoked on the bean instance. This is when the instance receives its reference to the EJBContext for its lifetime. The SessionContext reference may be stored in a nontransient instance field of the stateless session bean. Everything a stateless session bean method needs to know has to be passed via the method's parameters. The only exception to this rule is information obtainable from the SessionContext and in EJB 1.1, the JNDI ENC.�[O�reilly EJB book]. Hence if only one instance of a stateless session bean is shared by multiple EJBObjects, how that one instance will be able to get a reference to its corresponding EJBObect through its nontransient sessioncontext field?
1)�Beans that are involved in transactions are subjected to the isolated ACID property, which means that their services cannot be shared during the life of the transaction.� [O�reilly EJB book]. If my interpretation of �services cannot be shared� is correct, then that means no other client can access the same method of the stateless session bean already involved in a transaction. Hence just having one instance of a stateless session bean will be a bottleneck if it is involved in a transaction.
2)�When a system exception occurs, the bean instance is discarded, which means that it's dereferenced and garbage collected. The container assumes that the bean instance may have corrupt variables or otherwise be unstable, and is therefore unsafe to use. The impact of discarding a bean instance depends on the bean's type. In the case of stateless session beans and entity beans, the client does not notice that the instance was discarded. These types of beans are not dedicated to a particular client; they are swapped in and out of an instance pool, so any instance can service a new request.� [O�reilly EJB book]. Hence having only one instance of a stateless bean can impact the availability of the service it offers in case a system exception occurs in one of its methods while serving a client request.
3)�If, however, the session bean is managing database data for the user, it may want to know about the beginning and ending of user transactions, so that it can cache data at the start and commit its database updates at the end. For this reason, the EJB specification allows session beans to optionally implement the javax.ejb.SessionSynchronization interface. By implementing this interface, the session bean indicates that it wants the container to notify it about the beginning and end of transactions.� [O�reilly EJB book]. This is related to point no. 1) above � �Session beans involved in transaction�. Though use of SessionSynchronization may make more sense for a stateful session bean, it is still available for stateless beans. Hence I am not sure how only one instance of a stateless session bean serving many clients can handle SessionSynchronization in a transaction.
4)�The SessionBean.setSessionContext(SessionContextcontext) method is invoked on the bean instance. This is when the instance receives its reference to the EJBContext for its lifetime. The SessionContext reference may be stored in a nontransient instance field of the stateless session bean. Everything a stateless session bean method needs to know has to be passed via the method's parameters. The only exception to this rule is information obtainable from the SessionContext and in EJB 1.1, the JNDI ENC.�[O�reilly EJB book]. Hence if only one instance of a stateless session bean is shared by multiple EJBObjects, how that one instance will be able to get a reference to its corresponding EJBObect through its nontransient sessioncontext field?
扫一扫
21万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
