EJB3 Entity doing Batch Insert fails with transaction requir

[ejb3workshop]

I am reading a rather large XML file, split it into a large number of segments and would like to insert each segment into a database. The segments fit nicely into entities, so please don't tell me about prepared statement etc. Currently I have MDB which received the file descriptor and begins reading the file and processing it.

When using smaller files (<30Mb) everything seems to work really well. The files are loaded quickly and without errors. However as soon as the I try to load the large file the process failes with :

javax.persistence.TransactionRequiredException: EntityManager must be access within a transaction
at org.jboss.ejb3.entity.ManagedEntityManagerFactory.verifyInTx(ManagedEntityManagerFactory.java:150)
at org.jboss.ejb3.entity.TransactionScopedEntityManager.persist(TransactionScopedEntityManager.java:181)
at com.abc.backend.BatchJobDevider.segmentCompleted(BatchJobDevider.java:56)
at com.abc.backend.utilities.XMLSegmenter.notifyListeners(XMLSegmenter.java:61)
at com.abc.backend.utilities.XMLSegmenter.segment(XMLSegmenter.java:51)
at com.abc.backend.BatchJobProcessor.onMessage(BatchJobProcessor.java:85)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:112)
at org.jboss.ejb3.interceptor.InvocationContextImpl.proceed(InvocationContextImpl.java:166)
at org.jboss.ejb3.interceptor.EJB3InterceptorsInterceptor.invoke(EJB3InterceptorsInterceptor.java:63)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.entity.TransactionScopedEntityManagerInterceptor.invoke(TransactionScopedEntityManagerInterceptor.java:54)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.AllowedOperationsInterceptor.invoke(AllowedOperationsInterceptor.java:47)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.aspects.tx.TxPolicy.invokeInCallerTx(TxPolicy.java:126)
at org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:195)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.stateless.StatelessInstanceInterceptor.invoke(StatelessInstanceInterceptor.java:62)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.mdb.MessagingContainer.localInvoke(MessagingContainer.java:245)
at org.jboss.ejb3.mdb.inflow.MessageInflowLocalProxy.delivery(MessageInflowLocalProxy.java:268)
at org.jboss.ejb3.mdb.inflow.MessageInflowLocalProxy.invoke(MessageInflowLocalProxy.java:138)
at $Proxy99.onMessage(Unknown Source)
at org.jboss.resource.adapter.jms.inflow.JmsServerSession.onMessage(JmsServerSession.java:178)
at org.jboss.mq.SpyMessageConsumer.sessionConsumerProcessMessage(SpyMessageConsumer.java:891)
at org.jboss.mq.SpyMessageConsumer.addMessage(SpyMessageConsumer.java:170)
at org.jboss.mq.SpySession.run(SpySession.java:323)
at org.jboss.resource.adapter.jms.inflow.JmsServerSession.run(JmsServerSession.java:237)
at org.jboss.resource.work.WorkWrapper.execute(WorkWrapper.java:204)
at org.jboss.util.threadpool.BasicTaskWrapper.run(BasicTaskWrapper.java:275)
at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(PooledExecutor.java:743)
at java.lang.Thread.run(Thread.java:619)

Currently I don't have any transaction attributes defined on my onMessage method. At first I thought it might be the database connection pool timing out, so I increased the timeout. However I now get this failure before the timeout period elapsed. It seems that the transaction constructed by the server is exceeding some limit and then enters into a no transaction available state.

Any suggestions on how to resolve this without using a prepared statement and inserting it directly into the database.

Thanks
Alex

[alrubinger]

Any chance your UserTransaction is timing out?

If your point of entry (probably "onMessage") in your MDB) is starting the Tx, you can annotate it with @TransactionTimeout:

http://docs.jboss.org/ejb3/embedded/api/org/jboss/annotation/ejb/TransactionTimeout.html

...to get fine-grained control at the method level. Otherwise, globally:

http://wiki.jboss.org/wiki/Wiki.jsp?page=TransactionTimeout.

Course, I don't see a Tx timeout in your stacktrace...

So please post your MDB and the Message you're sending it? Where does the EM come into play in this equation?

S,
ALR

[ejb3workshop]

I don't have the code in front of me, but I will post it when I get to the office. But I can describe it briefly as it's pretty standard. It's a basic MDB with container managed transactions. Withing my onMessage method, I am calling the entityManager repeatedly asking it to persist a large number of objects. From the links you sent it seems that the timeout of 300 seconds (default) could well be the cause of my problem.

I will run some more tests tomorrow and get back to you.

Thanks for the link to the information.
Regards
Alex

[alrubinger]

Couple of things jump out at me:

1) If the method is taking more than 5 minutes to execute, very likely that the root of this problem is a UserTx timeout. I wouldn't futz with the global setting, but override on this method alone

2) Any tuning you can do to optimize those batch inserts? You mention "repeatedly asking [the EM] to persist a large number of objects". Check the section on JDBC Batch Inserts, flushing the EM, etc from the Hibernate Documentation:

http://www.hibernate.org/hib_docs/reference/en/html/batch.html

...though not directly related to your problem, you might be able to get some dramatic performance improvements, depending upon your current implementation.

S,
ALR

[ejb3workshop]

Managing the transaction in the bean allowed me to define the scope and duration of the TX. This solved my problem. Thanks for the links

Alex