BMP与CMP的选择要根据具体的业务来看,大部分情况用CMP是方便的是可以省很多事情的。
但银行等业务大部分就需要BMP
但银行等业务大部分就需要BMP
解决方案 »
- 项目启动报错严重: Exception starting filter struts2 Unable to load configuration. - [unk
- 进来看看。。。
- load十万条记录到内存,怎样尽量避免内存泄露?有经验的来..
- 框架
- struts2标签的问题
- 在线等~为什么我的连接池在tomcat5.59下老是包空指针异常
- session.createQuery得到的结果与数据库不同步????
- java.lang.NullPointerException异常处理问题
- struts的validate出错(javascript全部显示到界面上了)
- 我刚接触XML,对在JAVA里面应用解析XML很迷惑,请多指点.我怎么样才能把JAVA与XML结合起来?谢谢!
- 请问:在一个工程中定义了Local/Remote接口的实体bean,在另一个工程中Servlet可以调用,但是会话bean却找不到,这是怎么回事,如何解决
- ServiceLocator公共方法问题!
清单 1 显示了一段典型的 EJB 代码,它需要多次 JNDI 查找。请花一点时间研究代码,然后我们将对它进行优化以获得更佳性能。清单 1. 典型的 EJB 查找
public boolean buyItems(PaymentInfo paymentInfo, String storeName,
List items) {
// Load up the initial context
Context ctx = new InitialContext(); // Look up a bean's home interface
Object obj = ctx.lookup("java:comp/env/ejb/PurchaseHome");
PurchaseHome purchaseHome =
(PurchaseHome)PortableRemoteObject.narrow(obj, PurchaseHome.class);
Purchase purchase = purchaseHome.create(paymentInfo); // Work on the bean
for (Iterator i = items.iterator(); i.hasNext(); ) {
purchase.addItem((Item)i.next());
} // Look up another bean
Object obj = ctx.lookup("java:comp/env/ejb/InventoryHome");
InventoryHome inventoryHome =
(InventoryHome)PortableRemoteObject.narrow(obj, InventoryHome.class);
Inventory inventory = inventoryHome.findByStoreName(storeName); // Work on the bean
for (Iterator i = items.iterator(); i.hasNext(); )
inventory.AsSold((Item)i.next());
} // Do some other stuff
}
尽管这个示例多少有点刻意,但它确实揭示了使用 JNDI 时的一些最明显的问题。对于初学者,您应该问问自己,新建 InitialContext 对象是否必需。很可能在应用程序代码的其它地方已经装入了这个上下文,而我们又在这里创建了一个新的。高速缓存 InitialContext 实例会立即促使性能提高,如清单 2 所示:清单 2. 高速缓存 InitialContext 实例
public static Context getInitialContext() {
if (initialContext == null) {
initialContext = new InitialContext();
} return initialContext;
}
通过对 getInitialContext() 使用助手类,而不是为每个操作都实例化一个新的 InitialContext,我们将遍布在应用程序中的上下文数量减少为一个。哦 — 线程化会怎么样?
如果您对此处提出的解决方案的线程化感到担心,那大可不必。两个线程同时进行 getInitialContext() 是绝对有可能的(从而一次创建两个上下文),但只有首次调用该方法时才会发生此类错误。因为问题至多只会发生一次,所以同步是不必要的,实际上,同步引入的复杂性比它所解决的复杂性更多。
优化查找
高速缓存上下文实例这个步骤的方向是正确的,但仅这样做,还不足以完成优化。我们每次调用 lookup() 方法时都会执行一次新查找,并返回 bean 的 home 接口的新实例。至少,JNDI 查找通常是这样编码的。但如果每个 bean 都只有一个 home 接口,并在多个组件上共享这个接口,这样不是更好吗?我们可以高速缓存每个单独的 bean 引用,而不是反复查找 PurchaseHome 或 InventoryHome 的 home 接口;这是一种解决方案。但我们真正想要的是一种更通用的机制:在 EJB 应用程序中高速缓存 home 接口。答案是创建通用助手类,它既可以为应用程序中的每个 bean 获取初始上下文,又可以为它们查找 home 接口。此外,这个类还应该能够为各种应用程序组件管理每个 bean 的上下文。清单 3 中所示的通用助手类将充当 EJB home 接口的工厂:清单 3. EJB home 接口工厂
package com.ibm.ejb;import java.util.Map;
import javax.ejb.EJBHome;
import javax.naming.Context;
import javax.naming.InitialContext;
import javax.naming.NamingException;public class EJBHomeFactory { private static EJBHomeFactory; private Map homeInterfaces;
private Context context; // This is private, and can't be instantiated directly
private EJBHomeFactory() throws NamingException {
homeInterfaces = new HashMap(); // Get the context for caching purposes
context = new InitialContext(); /**
* In non-J2EE applications, you might need to load up
* a properties file and get this context manually. I've
* kept this simple for demonstration purposes.
*/
} public static EJBHomeFactory getInstance() throws NamingException {
// Not completely thread-safe, but good enough
// (see note in article)
if (instance == null) {
instance = new EJBHomeFactory();
}
return instance;
} public EJBHome lookup(String jndiName, Class homeInterfaceClass)
throws NamingException { // See if we already have this interface cached
EJBHome homeInterface = (EJBHome)homeInterfaces.get(homeClass); // If not, look up with the supplied JNDI name
if (homeInterface == null) {
Object obj = context.lookup(jndiName);
homeInterface =
(EJBHome)PortableRemoteObject.narrow(obj, homeInterfaceClass); // If this is a new ref, save for caching purposes
homeInterfaces.put(homeInterfaceClass, homeInterface);
}
return homeInterface;
}
}
EJBHomeFactory 类内幕
home 接口工厂的关键在 homeInterfaces 映射中。该映射存储了供使用的每个 bean 的 home 接口;这样,home 接口实例可以反复使用。您还应注意,映射中的关键并不是传递到 lookup() 方法的 JNDI 名称。将同一 home 接口绑定到不同 JNDI 名称是很常见的,但这样做会在您的映射中产生副本。通过依靠类本身,您就可以确保最终不会为同一个 bean 创建多个 home 接口。将新的 home 接口工厂类插入清单 1 的原始代码,这样将会产生优化的 EJB 查找,如清单 4 所示:清单 4. 改进的 EJB 查找
public boolean buyItems(PaymentInfo paymentInfo, String storeName,
List items) { EJBHomeFactory f = EJBHomeFactory.getInstance(); PurchaseHome purchaseHome =
(PurchaseHome)f.lookup("java:comp/env/ejb/PurchaseHome",
PurchaseHome.class);
Purchase purchase = purchaseHome.create(paymentInfo); // Work on the bean
for (Iterator i = items.iterator(); i.hasNext(); ) {
purchase.addItem((Item)i.next());
} InventoryHome inventoryHome =
(InventoryHome)f.lookup("java:comp/env/ejb/InventoryHome",
InventoryHome.class);
Inventory inventory = inventoryHome.findByStoreName(storeName); // Work on the bean
for (Iterator i = items.iterator(); i.hasNext(); ) {
inventory.AsSold((Item)i.next());
} // Do some other stuff
}
随着时间的推进,除了更清晰之外(至少按我的观点),以上工厂优化的 EJB 查找将执行得更快。您第一次使用这个新类时,将花费所有正常查找开销(假定应用程序的其它部分没有付出过这种开销),但将来的所有 JNDI 查找都将继续使用原先的查找结果。还有必要指出,home 接口工厂不会干扰您容器的bean 管理。容器管理的是 bean 实例,而不是这些 bean 实例的 home 接口。您的容器还将管理实例交换,以及其它您希望它执行的任何优化。
因为进行ejb调用是很耗资源的,应尽量减少该调用。
使用粗粒度的接口。
因此引入valueobject(数据对象)模式。将数据在服务器端“组装”好后一次返回给客户端可以有效提高性能。注意valueObject要实现insersialize接口以便在不同jvm间传递。
valueObject就是你的someArr。
--------------
记得把分给我。
我把代码贴出来。
比如:public class someArr implements Serializable {
......
}