|
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
最后更新时间：2004-02-04
只考虑性能的话，是否有必要在同一JVM中用Sessionless EJB?谢谢
声明：JavaEye文章版权属于作者，受法律保护。没有作者书面许可不得转载。
|
| 返回顶楼 | |
|
最后更新时间：2004-02-04
使用本地EJB，也比不使用要增加性能开销，不过这个开销相当小，毕竟没有远程方法调用或串行化。
|
| 返回顶楼 | |
|
最后更新时间：2004-02-11
还真没试过，建议写代码测试一下调用同一函数的时间。
|
| 返回顶楼 | |
|
最后更新时间：2004-02-12
今天早上花了两个小时把这个问题测试了一下。
开发环境：WSAD5.0 测试环境：WSAD5.0自带WS5.0 测试内容：在同一app中通过web应用，JSP调用sessionBean，用JSP调用JavaBean. 测试函数： public void counter() { for(int i = 0;i < 100;i++) System.out.println(i); } useSessionBean.jsp 主体： <BODY> <% long k =0; long i = System.currentTimeMillis(); Context initial = new InitialContext(); Object objref = initial.lookup("ejb/counterProcessHome"); counterProcessHome home = (counterProcessHome)PortableRemoteObject.narrow(objref,counterProcessHome.class); counterProcess counter = home.create(); counter.counter(); long j = System.currentTimeMillis(); k = j-i; %> <P>time cost:<%=k%></P> useJavaBean.jsp 主体： <% long k =0; long i =System.currentTimeMillis(); %> <jsp:useBean id="counter" class="com.test.counterJavaBean"/> <% counterJavaBean mycounter = (counterJavaBean) pageContext.getAttribute("counter"); mycounter.counter(); long j = System.currentTimeMillis(); k = j-i; %> <P>time cost:<%=k%></P> 运行结果(ms)： 第1次：sesionBean 359, javaBean 63 第2次：sesionBean 171, javaBean 125 第3次：sesionBean 62, javaBean 47 第4次：sesionBean 62, javaBean 46 第5次：sesionBean 47, javaBean 78 第6次：sesionBean 32, javaBean 31 第7次：sesionBean 63, javaBean 47 第8次：sesionBean 62, javaBean 63 第9次：sesionBean 63, javaBean 47 第10次：sesionBean 62, javaBean 47 以上的情况都是单次执行，没考虑并发，就这样吧，请各位分析分析。 |
| 返回顶楼 | |
|
最后更新时间：2004-02-12
多提交了一次，请斑竹删除。
|
| 返回顶楼 | |
|
最后更新时间：2004-02-12
自己可以删的。呵呵。
|
| 返回顶楼 | |
|
最后更新时间：2004-02-18
其实我们考虑性能，一般来说是分这样几个方面考虑，一、CPU的占用率，或者说耗费的CPU时间；二、内存的占用。
redforce的例子顶多只是在一种极端情况下的参考，不能作为基准的，furarmy对于本地接口的SessionBean还有些误解，它一样是会进行串行化的。SessionBean究竟具有什么优势呢？第一、对象的产生，如果多次大数据量的访问，那么普通的javaBean将产生非常多的实例，而不像SessionBean，只会有一个实例（当然是less的）。二、对于大数据量的访问，那么并发是个非常重要的问题，因为SessionBean的方法是同步的，那么自然在低数据量的情况下要比普通javaBean慢。 有人会说，那么我将javaBean做成singleton的方式行不行，当然行，只不过，你会发现带来很多的问题和潜在BUG。 所以说，我们不能单纯从一个方面去考虑性能，必须要综合机器性能、访问量、数据量多个方面。只能说在单机小数据量的情况下，javabean的CPU时间耗费性能要好些。 |
| 返回顶楼 | |
|
最后更新时间：2004-02-18
凤舞凰扬 写道 furarmy对于本地接口的SessionBean还有些误解，它一样是会进行串行化的。SessionBean究竟具有什么优势呢？第一、对象的产生，如果多次大数据量的访问，那么普通的javaBean将产生非常多的实例，而不像SessionBean，只会有一个实例（当然是less的）。二、对于大数据量的访问，那么并发是个非常重要的问题，因为SessionBean的方法是同步的，那么自然在低数据量的情况下要比普通javaBean慢。
老兄你没有配置过EJB吧？谁说SessionBean只有一个实例？容器会为每个SessionBean维护一个池，池内有一定数量的实例，决不是只有一个实例。由于创建一个EJB实例需要不少开销，所以使用一个实例池可以有效的减少实例化的次数从而提高性能。SessionBean的方法绝对不是同步的，你应该看看j2ee的规范。 |
| 返回顶楼 | |
|
最后更新时间：2004-02-18
此外，EJB容器会提供事务管理等其他一些功能使系统能够达到企业应用所需要的健壮度。所以普通的javabean虽然在实例化的时候会比EJB开销来的小，但却没有容器给EJB所能带来的好处，在企业应用中应当使用EJB尤其是SESSIONBEAN。
|
| 返回顶楼 | |
|
最后更新时间：2004-02-19
sayor,首先一点，EJB是有实例池，一般来说，对于一个statefulless的Session Bean只会产生一个实例（对于有状态的SessionBean是有多个实例的），当然，如果EJB容器设置事务属性是No Support，那么会产生多个实例，其实原因很简单，EJB必须实现事务的唯一性。同样，EJB是线程安全的，也就是说它是同步的，原因很简单：你可以想象两个不同的访问对同一个资源进行更新，而没有事务及同步的控制，那会是怎么样？？？
Statefulless的SessionBean并不是每一个需求就从实例池里取出或产生一个实例，而是共享同一个实例，也就是说在同一瞬间有多个访问对同一SessionBean进行访问，而同一瞬间却只能有一个方法被一个对象访问。事务的属性决定了线程安全，同样，事务的属性也决定了实例的产生。 sayor ， 该认真读读规范的是你啊～～～ |
| 返回顶楼 | |
