entity bean 代表一条数据,如果是显示数据,不要用entity bean  用bean +session bean +ado  , bean 封装数据集,ado连接数据操作;session 结合他们。你错误的理解了entity bean 。效率很低是因为你使用entity bean 的缘故

解决方案 »

  1.   

    to wkrain(花土沟的骆驼刺):
      可能你没理解我的意思,我说的是分页显示。如何分页?而不是用entity bean的问题。另外怎么搞出ado来啦?我们在Unix下开发东西,没有ado。
      

  2.   

    一个Entity Bean对应数据库中的一个表,一个Entity Bean的实例对应表中的一条记录你查询数据,其实是通过Session Bean做的,没有Entity Bean的事情:)你这里最主要的问题是想问如何解决大数据量数据在显示时的效率问题。我记得有办法处理的,似乎是先读出一定行数数据,然后在翻页的时候再去读下一段数据。
    不过很对不起,我没有做过,也只是脑子里有个印象。你可以在数据库版问问
      

  3.   

    我的问题就是解决大数据量数据在显示时的效率问题。我现在ejb1.2的finder函数只能把所有符合条件的都抓回来(至少我是这么认为)。
    大家有好的解决方法吗
      

  4.   

    你是说查询所有的数据纪录时间很长呢?
    还是显示?是不是你显示每一页的时候都要finder一把?
      

  5.   

    现在我的实现确实是要显示每一页的时候都finder一次。然后把find出来的数据集,再分页。每显示一页都需要把全部记录拿回来(我的finder是一个findall类型的)
      

  6.   

    可以将所有的查询回来的纪录保存到session bean的状态中,
    在显示的时候只是从session中读取未显示的,因该很快的,但是这样很可能
    在显示过程中数据不是最新的。而且第一次显示的时间比较长
    可以考虑:
    每一次只是查询你要显示的数据,在session 中保存已经显示了的数据的key,查询的时候查询还没有显示的key的数据,而且只是查询前规定的那么多条记录
      

  7.   

    to ggyy(夕阳枯树,小桥流水无家,孤独人流浪天涯) :
      你说的确实是一个方法,但是显示的数据不是最新的。同时如果用有状态的session bean会增加服务器的负担的,我想这个问题在数据很大时很严重。
    finder函数只能返回Enumeration类型的值(EJB1.2),而Enumeration只能单向的向前一条一条记录的向前移动,如果数据很大,我要显示最后一页,就需要从第一页(也就是第一条记录)开始移动,这个速度应该很慢啊。
      

  8.   

    如果直接用sql 语言,可以用rownum来选定所需要的纪录。
    用stateful sb恐怕问题会很大。我也遇到了同样的问题,有人能提点一下吗?我觉得楼上的几位都没有理解问题本身。
      

  9.   

    to charleyshen(shenpf):
        如用sql可以的话,那么应该可以达到我的要求,但是请问一下如何使用rownum呢。抱歉我的sql不太熟悉。
      

  10.   

    我觉得涉及到分页的时候最好绕过entity bean,通过session bean直接获得ResultSet,这样的效率肯定会高一些,但是这样的话,对结构有一定的影响
    可能要视具体情况做取舍
      

  11.   

    ado  不是微软的哪个,我是说 access data object  你自己写推荐一个方法不一定好    同过sql语句来分页    set @x =  min(...)向前
          
          select top n  @x=id from  a  wher id >@x
     
    向后
            
          select top n  @x=id from  a where id<@x在程序中记录 主建的大小来 用 
           
     
      

  12.   

    在SUN的建议解决方案中是不赞成用entity bean去检索大量的数据的,应为每行数据都需要建立一个bean,这样对系统是极大的负担。建议方案是采用session bean来完成检索的工作。
    相信用session bean的解决方法你是知道得啦!:)
      

  13.   

    在对大数据量的数据进行检索时最好使用session bean+数据库存储过程,尽可能的提高速度,至于分页,从数据库级别的分段查找是最快的,但这和具体数据库的支持是有关的。
      

  14.   

    我使用的是DB2的数据库,我也觉得使用数据库级别的分页是最快的,但是很可惜本人sql不熟悉,还想请教各位如何做。使用ResultSet的确效率会提高,但是结构的损失就很惨啦,而且感觉上复杂性的增加也不少啊。大家都讨论讨论,看看什么方法最好。
      

  15.   

    session bean中使用ResultSet仅仅用于检索多个表或大量数据的检索,这样即不会对结构有多大改动,更重要的是它大大的提高了系统的性能!
    设计系统不能仅仅局限于貌似完整的结构,更重要的是考虑扩展性和性能!扩展性并不仅仅有结构就可以了,对于性能来说大量的对象的创建是需要尽量避免的!
    你可以专门写一个session bean以实现数据检索的功能。另一session bean条用entity bean以及数据检索的session bean。具体实现数据检索的分页思路见下:我们一般创建statement是这样写的:
    stmt = con.createStatement();该方法在JDBC 1.0 中唯一可用的方法。在 JDBC 2.0 中,存在着允许创建可滚动的 ResultSet 新方法: 
    createStatement( 
       int resultSetType, 
       ResultSet.CONCUR_READ_ONLY)其中resultSetType 可以是以下三种: 
    1.ResultSet.TYPE_FORWARD_ONLY--这是默认值,和 JDBC 1.0 中的一样:仅转 交移动,列一般地仅能读取一次。在 ResultSet.next() 返回 false 时, ResultSet 数据就不再有效并自动关 闭。2.ResultSet.TYPE_SCROLL_INSENSITIVE 允许创建 ResultSet, 其中的光标可以向后、向前和随机移动。这是静态数据:数据库中对当前 ResultSet 中选定的行进行的任何更改都是不可见的。也就是说, ResultSet 对数据修改不敏感。3.ResultSet.TYPE_SCROLL_SENSITIVE 允许创建 ResultSet,其 中的光标可以向后、向前和随机移动。这提供了数据的动态视图:数据库中对当 前 ResultSet 中选定的行进行的任何更改都是可见的。也就是说, ResultSet 对数据修改很敏感。若我们采用后面两种,那么就可以实现数据分批返回了。这样就可以实现分页功能了。
      

  16.   

    to  wkrain(花土沟的骆驼刺):
    那个是Data Access Object  DAO,你别误导人家了
      

  17.   

    现在我感觉如果使用ResultSet似乎没有必要使用session bean啦。在sevlet里面也可以完成这些工作的。大家觉得2者是否有区别?我感觉好像前者更耗资源哦。
      

  18.   

    如果完全只考虑资源,那么在jsp或servlet中直接用jdbc是最好的了,但是你要考虑系统的扩展性,如果在servlet中直接用的话,你的业务逻辑在哪处理?怎么扩展?是否考虑过呢?
      

  19.   

    我觉得不能为结构而结构, 只要达到扩展性的要求就好了.所以我认为使用Session+JDBC比较合理, 实现时可以依照数据库不同做一些优化(有些数据库支持在Select语句中指定范围);另外, 返回值建议使用CachedRowSet, 这样查询结束就可以释放Connection, 但查询结果依然保留在Bean中.EntityBean 是个鸡肋, 用不用都可以.
      

  20.   

    http://java.sun.com/blueprints/corej2eepatterns/Patterns/ValueListHandler.html
      

  21.   

    如果是效率的问题,我的建议是在entity bean中用find方法找出满足查询条件的所有记录的主键,存在SessionBean中。然后对这些主键数据进行分页,在页面载入时,先取得该页的主键数据,然后再根据主键数据到数据库中查找详细数据信息。这样效率高点。    如果要谈到数据的同步问题,到现在为止我也没有见到很好的解决方法。甚至说没有解决方法。因为大部分数据库不支持在检索时就进行分页(或者说没有从满足条件的记录中返回1-10条记录这样的功能),所以根本就不可能实现。    
      

  22.   

    可能要用到这些知识:
    1.JSP 中Taglib
    写两个TagLib:PageToPage.java负责生成翻页的JSP代码(如第一页,前一页,后一页,最后页操作的jsp代码);
    PageDataControl.java负责拿数据放入request或session中;
    2.JSP只是负责从request或session中取数据;
    3.DAO(Date Access Object)
    负责从数据库中取数据,如果是Oracle,可以用(rownum between 1,10);如果数据库不支持,可以考虑用JAVA程序如拿(最好使用
    前测试一下在数据库有上百万数据时,翻到最后几页的效率)
    //Page 是页面传过来的要去到的页数,count是一页多少条记录
            Collectin resultList = new ArrayList();
            if (Page >= 0 && rs.absolute(Page*count+1))
               {
                   do
                   {
                       ValueObject valueObject= new ValueObject();
       valueObject.setXXX(rs.getString(1));
       ....
                       resultList.add(valueObject);
                   }
                   while ((rs.next()) && (--count > 0));
               }
             else
             {
                 System.out.println("No records");
             }
      

  23.   

    是否可以用ValueObject来实现呢? 在CSDN上很少有人讨论ValueObject(VO), 这个东西可能会很好用. 从Sun的VO模式文档上看, RemoteEntityBean在set/get时会造成巨大的网络开销, 所以用一个VO会好些. 也许用LocalEntityBean不会有网络开销, 但是CMP要实现分页(通常是某种检索结果)没有标准方法, 使用了特定于某厂商的分页方案当然不是好办法. 因此还是Session+JDBC会好些. 用了JDBC的分页的方式就很灵活了, 疯狂的rs.next()或者用可以SCROLL的rs都可以轻松实现.查询到了ResultSet, 可以用CachedRowSet, CRS不是强类型的, 只能用getString("xxx"), 而不是getXxxx(), 编译时很难检查错误, 这时候可以考虑VO: 给ValueObject加上一个方法: VO[] createFromRS(ResultSet rs), 方法里面只是HardCoding的this.xxx = rs.getString(xxx);这样你的Session中全都用VO来做接口啦, 数据校验(逻辑检查)也可以放到里面. 目前只看到Together6可以生产VO, 而且VO没有createFromRS().用了VO以后可能会形成这样的结构:
    SessionBean对外接口用VO, 对内操作用Entity. 这样外面的调用者也不用care数据是Remote还是Local.