可以给一个简单的例子吗? 比如 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 这样的语句应该怎样写呢?谢谢,解决后马上给分!
棘手啊,用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了! 这种问题怎么解决呢?
用EntityBean查询结果集会耗用很多服务器的内存吗?
比如
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
这样的语句应该怎样写呢?谢谢,解决后马上给分!
方法 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了!
这种问题怎么解决呢?
数据结果集,当然也可以用SessionBean的,只是里面的属性换成集合变量,如list,
用它来存取多条记录,每一个集合变量对应数据库中的一个字段!
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直接存取数据库的方式,应该对数据访问逻辑加