我尝试在Glassfish 3.0.1中使用JPA在MySQL 5.1中插入360万条记录。我在一个EJB业务方法调用中完成它，所以我相信它是在一个单独的SQL事务中完成的。我疯了吗？ ： - ）
由于使用了相同的EntityManager实例，因此业务方法必须每3000个记录调用em.flush（）和em.clear（），否则em将阻塞。 （我尝试了各种各样的值，这对我来说似乎是最佳的。）
这在我的测试和开发平台（四核盒子上的WinXP）上非常有效。每个100000 em.persist（）需要24-28秒，整个操作需要15分钟。
但是在我们的生产盒上，在虚拟化的x86_64盒子上使用Ubuntu 10，每个100000 em.persist（）逐渐变慢。第一个需要40秒，然后是70,77,89,121,130,126,163,201,247秒。服务器应用程序最终会挂起。
MySQL的： 5.1.47社区MySQL社区服务器（GPL）（Windows）， 5.1.41-3ubuntu12.6（Ubuntu）
我无法弄清楚为什么（几乎）相同的软件表现得如此根本不同。有什么想法吗？
答案 0 :(得分：0)
答案 1 :(得分：0)
不要尝试在一次交易中提交360万条记录。我认为你通过执行定期的em.flush（）和em.clear（）来减轻JVM的负担，但这对于另一端需要管理360万新回滚数据的数据库没有帮助记录，直到你最终提交它们。
您是否在与Java应用程序相同的服务器上托管数据库？也许数据库是瓶颈而不是Java代码。尝试检查两个环境中各种进程的内存和CPU使用情况。很明显，Java或数据库服务器正在耗尽所有内存或CPU。
答案 2 :(得分：0)
EJB / JPA没有（afaik）给我一个选择; EJB容器处理事务并在业务方法返回时提交它。也许有一种方法可以告诉EJB每次业务方法创建10000个实体时都要提交......
（当然，我可以直接使用JDBC来做到这一点，但这样做会在JPA下发挥作用。）
但奇怪的是，这两台机器的行为有所不同。