EJB3.0的有状态Bean与无状态Bean的最基础问题
初学EJB写了个HelloWorld还遇到困难了,我先是写了一个无状态Bean运行正常没问题,然后准备再写一个有状态Bean,这个有状态Bean是不是就是把@Statel...
初学EJB写了个HelloWorld还遇到困难了,我先是写了一个无状态Bean运行正常没问题,然后准备再写一个有状态Bean,这个有状态Bean是不是就是把@Stateless改成@Stateful就行了吧~ 我看书上也这么说,写法没什么区别,可是就出问题了,有状态Bean报类型转换异常,代码如下:
这个是定义的远程接口,有状态实现类,以及客户端调用,还有报出的错误
我就是把原先IHelloBean上面的@Stateless换成了现在的@Stateful别的一概没动,就出这个错了,原先的@Stateless运行完全正常,请问这是怎么回事?是不是写有状态bean除了修改这个注解还有别的地方要改? 展开
这个是定义的远程接口,有状态实现类,以及客户端调用,还有报出的错误
我就是把原先IHelloBean上面的@Stateless换成了现在的@Stateful别的一概没动,就出这个错了,原先的@Stateless运行完全正常,请问这是怎么回事?是不是写有状态bean除了修改这个注解还有别的地方要改? 展开
1个回答
展开全部
规范里面说对于远程的引用应该是 javax.rmi.PortableRemoteObject.narrow(object, IHello.class);
之后再 Cast 成 IHello, 因为在同一个 JVM 中的 Local EJB 没有远程操作带来的额外步骤,因此那个EJB对象在同一个JVM中直接给你就行了,但远程的则不同,通信层可以根据它自己的算法使用不同的方法,只要保证最后 PortableRemoteObject.narrow 返回的东西符合规范要求就可以了。
还有一点很重要的,有状态的 EJB 表示,当我们 create 一个 EJB 实例后并且在 remove 之前,后续的操作在服务器远程端都会对应同一个 EJB 实例来为我们服务,因此如果它有一些字段来记录上次操作的值的话就可以保持连续性,这就叫有状态。而无状态EJB在 create EJB 后连续发起的 EJB 操作远程服务器可以随机选择任意一个 EJB 对象实例来为我们服务,因此如果你在某个字段上保存了上次操作的值,那它是不能连续的,所以说无状态的 EJB 是不应该有成员变量的。而有状态EJB可以有成员变量。另外对于无状态EJB所有的实例其实可以共享,所以一般无状态的EJB可以启用 Enable Share Context 的选项,因为它肯定是线程安全的(它没有成员变量嘛),而有状态则不会有这个功能。因此,在 lookup 一个无状态 EJB 容器帮我们自动把 Home 接口调用一个 create 功能得到一个 business 接口的实例就是合情合理的,也是 EJB 3 简化的依据(我曾经在服务器上部署了一个 EJB 2.0 的无状态 EJB,然后在一个客户端中使用 EJB 3 调用它成功了,所以说内部实现其实还是基于 EJB 2.0 相同的原理和技术,只是把某些东西自动化了),但有状态 EJB 则问题复杂些。你可以通过把你 lookup 得到的 object 的父类和它实现的接口的列表打印出来,我们可以从这些接口的类名推测出它是什么东西,object.getClass().getInterfaces() 这个数组跑个循环打印它每个 interface 的类名来。我们能猜测一个它是什么。
之后再 Cast 成 IHello, 因为在同一个 JVM 中的 Local EJB 没有远程操作带来的额外步骤,因此那个EJB对象在同一个JVM中直接给你就行了,但远程的则不同,通信层可以根据它自己的算法使用不同的方法,只要保证最后 PortableRemoteObject.narrow 返回的东西符合规范要求就可以了。
还有一点很重要的,有状态的 EJB 表示,当我们 create 一个 EJB 实例后并且在 remove 之前,后续的操作在服务器远程端都会对应同一个 EJB 实例来为我们服务,因此如果它有一些字段来记录上次操作的值的话就可以保持连续性,这就叫有状态。而无状态EJB在 create EJB 后连续发起的 EJB 操作远程服务器可以随机选择任意一个 EJB 对象实例来为我们服务,因此如果你在某个字段上保存了上次操作的值,那它是不能连续的,所以说无状态的 EJB 是不应该有成员变量的。而有状态EJB可以有成员变量。另外对于无状态EJB所有的实例其实可以共享,所以一般无状态的EJB可以启用 Enable Share Context 的选项,因为它肯定是线程安全的(它没有成员变量嘛),而有状态则不会有这个功能。因此,在 lookup 一个无状态 EJB 容器帮我们自动把 Home 接口调用一个 create 功能得到一个 business 接口的实例就是合情合理的,也是 EJB 3 简化的依据(我曾经在服务器上部署了一个 EJB 2.0 的无状态 EJB,然后在一个客户端中使用 EJB 3 调用它成功了,所以说内部实现其实还是基于 EJB 2.0 相同的原理和技术,只是把某些东西自动化了),但有状态 EJB 则问题复杂些。你可以通过把你 lookup 得到的 object 的父类和它实现的接口的列表打印出来,我们可以从这些接口的类名推测出它是什么东西,object.getClass().getInterfaces() 这个数组跑个循环打印它每个 interface 的类名来。我们能猜测一个它是什么。
已赞过
已踩过<
评论
收起
你对这个回答的评价是?
推荐律师服务:
若未解决您的问题,请您详细描述您的问题,通过百度律临进行免费专业咨询