我们的项目是在EJB 2.0中设计的。
我们没有在BMP EntityBeans中使用任何EJB持久性方法。在SessionBeans中，我们通过使用getEJBXXXXHome()方法获得对EntityHome对象的引用，并通过调用home.findByPrimaryKey(")方法获得EJB引用。然后我们调用CRUD操作的实际方法。在CRUD操作方法中，我们使用的是普通的JDBC API方法。
现在我们正在迁移到EJB3。作为从EJB 2.0到EJB3迁移的一部分，我正在将所有BMP entitybean转换为普通的Java类，即不再有entitybean。如果EJB容器先前为实体bean维护了一个池，那么它现在就不会存在了。当我在本地机器上测试一个事务时，它工作正常
我担心的是，它会影响生产环境中多线程的性能吗?
现在修改代码后，每个调用创建一个EntityBean对象。如果在一小时内打了6万个电话，会影响我的服务器吗?以前在EJB 2.0中是如何处理这个问题的?是否有任何方法可以在更改的代码中处理它(即对于正常的Java类，因为它们不再是实体bean概念)
一般来说，创建/收集异议的开销将低于EJB容器先前为您的实体所做的任何工作的开销。我怀疑比对象创建开销更大的问题是到数据库的往返。根据您的EJB容器配置，容器可能正在优化JDBC SQL并可能缓存检索到的数据(与对象缓存无关)。在设计应用程序时，应该尽量减少对数据库的调用，并确保不执行不必要的查询。
最终，我怀疑只有您能够在您的应用服务器和您的硬件上评估您的应用程序的性能。我建议遵循良好的编程实践，以避免过度的开销，分析结果，并从那里进行优化，而不是预先担心性能。