当然是entity bean啊,实体bean就是代表数据库的一条记录。

解决方案 »

  1.   

    可是如果是大批量的数据查询也可以用EntityBean吗?
    用EntityBean查询结果集会耗用很多服务器的内存吗?
      

  2.   

    当然是用EntityBean了,这是为什么使用他的原因,如果你不用她,那为什么还要用ejb啊,不如就用javabean酸了。
      

  3.   

    可以给一个简单的例子吗?
    比如
    select OBJECT(p) from table p where p.id < 10
    返回10条纪录,用CMP的add finder增加一个查询,这样会耗用很多的内存吗?如果是复杂的查询呢?比如
    select top 40 * from (select top 1000 * from table order by cast(id as int)) as aa order by cast(id as int) desc
    这样的语句应该怎样写呢?谢谢,解决后马上给分!
      

  4.   

    棘手啊,用CMP做一个简单的查询,表中有10000条纪录
    方法  public Collection findByPage() throws FinderException, RemoteException;EJB QL:SELECT OBJECT(bb) FROM table as bb client端:
    Iterator it = userHome.findByPage().iterator();
    (执行完这句以后,看weblogic的console的Entity EJBRuntimes)结果如下:
    Idle Beans Count              1
    Beans In Use Count            10000
    Waiter Total Count            0
    Timeout Total Count           0
    Cached Beans Current Count    1000
    Cache Access Count            0
    Cache Hit Count               0
    Activation Count              10000
    Passivation Count             0
    Lock Entries Current Count    0
    Lock Manager Access Count     0
    Waiter Total Count            0
    Timeout Total Count           0
    使用中的Bean 10000?查询几次以后就报cacheFullException了!
    这种问题怎么解决呢?
      

  5.   

    个人认为对于涉及到复合查询和返回多条记录的查询语句最好自已写一类封装
    数据结果集,当然也可以用SessionBean的,只是里面的属性换成集合变量,如list,
    用它来存取多条记录,每一个集合变量对应数据库中的一个字段!
      

  6.   

    1.远程对象和本地对象。Entity Bean是远程对象,而DAO是本地对象。因此对Entity Bean的访问速度要比对DAO的访问速度要低。 
    2.容器管理的生命周期和客户管理的生命周期。Entity Bean的生命周期由容器管理,而DAO的生命周期由使用它的客户(一般是Session Bean)管理。在容器管理的生命周期中对Entity Bean的修改和实际数据库记录的更新分别有客户和容器完成,单个Entity Bean的修改性能要比单个DAO对象的修改高。在批量数据的处理上,由于DAO是一次性完成,性能比Entity Bean要好。 
    3.Session Bean管理事务和Entity Bean管理事务。DAO的事务有客户(一般是Session Bean)负责,Entity Bean的事务由Entity Bean自身完成。Session Bean事务适合粗粒度的事务控制,而Entity Bean事务适合细粒度的控制。 
    4.脏数据问题。一般来说我们采用value Object避免大量的琐碎的远程调用来获取数据,同时这也会给我们带来所谓的“脏数据”问题。在Entity Bean中可以使用Time Stamp来解决这个问题,但DAO看起来似乎难以解决。 
    5.资源问题和激活/钝化瓶颈。大量的Entity Bean会消耗大量的资源,DAO同样如此。Entity Bean设计的目的不是为了操纵批量数据,而DAO是一般Java对象,可以这样使用。在Entity Bean或DAO对象数量巨大时,Entity Bean由容器管理其激活和钝化,以节省资源;而DAO对象需要自己设计这种机制,这是很困难的。同时管理DAO对象的Session Bean的激活和钝化过程会带来DAO对象的存储瓶颈,即在Session Bean的激活和钝化中,其所管理的DAO对象也要被写入外存储器。 
    6.缓冲的实现。Entity Bean由容器实现缓冲(Cache),DAO对象本身很难实现缓冲机制。 
    一般在只读的应用中使用DAO,而在创建和修改操作中使用Entity Bean。不建议使用Session Bean直接存取数据库的方式,应该对数据访问逻辑加