[
https://issues.apache.org/jira/browse/OPENEJB-1968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13530791#comment-13530791
]
Howard W. Smith, Jr. commented on OPENEJB-1968:
-----------------------------------------------
@TransactionAttribute(value = TransactionAttributeType.REQUIRES_NEW)
had same test results...too.
My next attempt/implementation involves the following:
1. Move all the logic of @Stateless EJB @Schedule getEmails() to @Asynchronous
getEmails() on CDI @ApplicationScoped bean
2. Add a new method on CDI @ApplicationScoped bean called
makeAsyncCallToGetEmails(), which will be called by @Stateless EJB @Schedule
getEmails()
3. makeAsyncCallToGetEmails() will invoke @Asynchronous getEmails()
So far, the test results are below. It's interesting/strange that TomEE (the
container) invokes the @Asynchronous getEmails() 'immediately' after
TomEE/container completed 'start'. See log below and look at the time; I set
the @Schedule to be 15 minutes. All the prior tests (without @Asynchronous),
@Schedule getEmails() was invoked every 15 minutes...working as designed. Is
this a bug or feature of TomEE to invoke @Asynchronous on CDI
@ApplicationScoped bean immediately after TomEE/container starts???
Well, the end result is same exception as before with a few more debug lines.
See below.
Dec 13, 2012 3:12:07 AM org.apache.catalina.startup.Catalina start
INFO: Server startup in 38783 ms
Dec 13, 2012 3:16:32 AM org.apache.myfaces.el.unified.ResolverBuilderBase
sortELResolvers
INFO: Chain of EL resolvers for Faces sorted with:
org.apache.myfaces.el.unified.OpenWebBeansELResolverComparator@32735 and the
result order is
[org.apache.myfaces.el.unified.resolver.implicitobject.ImplicitObjectResolver@1032447,
org.apache.myfaces.el.unified.resolver.CompositeComponentELResolver@142b5f0,
org.apache.myfaces.el.FlashELResolver@b6b6c6,
org.apache.myfaces.el.unified.resolver.ManagedBeanResolver@199be0d,
org.apache.myfaces.el.unified.resolver.ResourceResolver@8c7362,
javax.el.ResourceBundleELResolver@eb5873,
org.apache.myfaces.el.unified.resolver.ResourceBundleResolver@fbf8f4,
javax.el.MapELResolver@9587c9, javax.el.ListELResolver@105ba24,
javax.el.ArrayELResolver@ffc33f, javax.el.BeanELResolver@16b7d69,
org.apache.webbeans.el.WebBeansELResolver@1f67d53]
Dec 13, 2012 3:21:35 AM pf.ApplicationScopeBean log
INFO: ApplicationScopeBean.processAirportShuttleRequest(): ADD Airport Shuttle
- Flight # 1 SUCCESSFULLY for 01/06/2013
Dec 13, 2012 3:29:10 AM pf.ApplicationScopeBean log
INFO: ApplicationScopeBean.processAirportShuttleRequest(): ADD Airport Shuttle
- Flight # 2 SUCCESSFULLY for 01/18/2012
Dec 13, 2012 3:29:11 AM pf.ApplicationScopeBean log
INFO: ApplicationScopeBean.makeAsyncCallToGetEmails(): getEmails() returned
javax.ejb.AsyncResult@1baecd3
Dec 13, 2012 3:29:19 AM org.apache.openejb.core.timer.EjbTimerServiceImpl
ejbTimeout
WARNING: Exception occured while completing container transaction
javax.transaction.RollbackException: Unable to commit: transaction marked for
rollback
at
org.apache.geronimo.transaction.manager.TransactionImpl.commit(TransactionImpl.java:272)
at
org.apache.geronimo.transaction.manager.TransactionManagerImpl.commit(TransactionManagerImpl.java:252)
at
org.apache.openejb.core.timer.EjbTimerServiceImpl.ejbTimeout(EjbTimerServiceImpl.java:598)
at
org.apache.openejb.core.timer.EjbTimeoutJob.execute(EjbTimeoutJob.java:39)
at org.quartz.core.JobRunShell.run(JobRunShell.java:213)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Caused by: java.lang.Exception: Transaction has timed out
at
org.apache.geronimo.transaction.manager.TransactionImpl.commit(TransactionImpl.java:266)
... 7 more
Dec 13, 2012 3:29:20 AM pf.ApplicationScopeBean log
INFO: ApplicationScopeBean.makeAsyncCallToGetEmails(): getEmails() returned
javax.ejb.AsyncResult@e72662
Dec 13, 2012 3:30:01 AM pf.ApplicationScopeBean log
INFO: ApplicationScopeBean.makeAsyncCallToGetEmails(): getEmails() returned
javax.ejb.AsyncResult@bafb73
> @Stateless EJB with @Schedule method and single EntityManager/transaction
> does not perform well and holds transaction
> ---------------------------------------------------------------------------------------------------------------------
>
> Key: OPENEJB-1968
> URL: https://issues.apache.org/jira/browse/OPENEJB-1968
> Project: OpenEJB
> Issue Type: Bug
> Components: ejb31
> Affects Versions: 4.5.0
> Environment: TomEE 1.5.1
> Windows Server 2003 32bit 4GB RAM
> Reporter: Howard W. Smith, Jr.
> Labels: @Stateless, EJB, entitymanager, transaction
> Attachments: EmailStatelessBean.java, tomcat7-stderr.2012-12-12.log
>
> Original Estimate: 504h
> Remaining Estimate: 504h
>
> After implementing 'workaround' option # 1 in my previous email (below), the
> test results were really really bad. :(
> for 4 emails, it took 30 minutes to insert the data into the database, and
> then it seemed as though the single @Stateless EJB held onto the transaction,
> even after the @Schedule method, getEmails(), was done and exited.
> Should I file a JIRA? I would assume that the @Stateless bean would 'let go'
> of the transaction, but transaction remained opened. Maybe, I should have
> issued a entityManager.flush() after completing each email, but I did flush()
> a lot throughout the process.
> Please note that this machine is Windows Server 2003 32bit 4GB RAM, and it
> takes 10 to 15 minutes to insert data from 2 emails (which is a very small
> amount of data embedded in the email). I could not select any data from
> database after login. I had to shutdown TomEE.
> Also, note, when I originally developed this, one @Stateless EJB with 1
> entity manager, it took 2 seconds on Windows Server 2008 64bit 16GB RAM, and
> it did not hold the transaction (or database locks). also, i could select
> data afterwards.
> I still need to try what David mentioned, but it's been an all-nighter for
> me, so i need to stop right here for now.
> I think I will open a JIRA for this.
> On Tue, Dec 11, 2012 at 10:10 PM, Howard W. Smith, Jr.
> <[email protected]> wrote:
> Shaking my head... test results were not good at all.
> 1. @StatelessEJB EmailStatelessBean has @Schedule getEmails()
> 2. @EmailStatelessBean has multiple @EJB references to @Stateless
> (sessionfacade) classes that are the DAO classes
> 3. EmailStatelessBean gets invoked when triggered by @Schedule
> 4. EmailStatelessBean execution locks the tables, still, and locks up the
> entire app, and seems to take longer...since endusers (myself) are making
> requests against database (and web app).
> 5. Last but not least, EmailStatelessBean failed to commit the changes;
> transaction rolled back for EmailStatelessBean as well as enduser requests.
> So, my workaround options include the following:
> 1. EmailStatelessBean, when invoked by @Schedule method, will check the CDI
> @ApplicationScoped bean (ApplicationScopeBean), and see if any endusers are
> logged in; i developed a sessionInfo class that is updated everytime enduser
> does a HTTP request; if any endusers are logged in, then I can use Atmosphere
> (PrimeFaces Push) to push a message to the endusers, notifying them to
> 'please logout, as there are customer requests pending that need to be
> retrieved and inserted into the web app's database', and EmailStatelessBean
> will 'return' (or exit) and not perform the operation. This way, everytime
> @Schedule invokes the bean method, it will continue to check for an available
> time to perform the get-emails-and-insert-into-database operation. Also, I'll
> set when EmailStatelessBean begins the operation, then I'll set flag on
> @ApplicationScoped bean (insertingCustomerRequestsIntoDatabase = true); this
> flag will be checked when endusers attempt to login web app, and FacesMessage
> will be displayed, Please login a few minutes later as system is inserting
> customer requests into database.
> 2. Another option would be to send a message to all clients via Atmosphere
> (PrimeFaces Push), and the UI will be locked immediately, and user will be
> required to wait.
> Honestly, I don't like either of these approaches, but I think the endusers
> will accept the 1st option (above). If I go with 1st approach, then I may
> revert back to single transaction, which will complete the entire operation
> much faster than multiple transactions (via multiple EJB DAO classes).
> As you can see, I don't have enough experience locking database for such a
> batch operation as this. I know the endusers want the customer requests to
> show up into the database 'immediately', and they want to know when it
> happens. Right now, this is my only option until I redesign the business
> website to interface directly with the web app. right now, the web app is
> 'only' used by 'personnel' (the owners of the business...which is my family).
> hahaha :)
> They love the app (honestly, they liked the speed and reliability of the web
> app when it was on Glassfish), but I'm doing all i can to win them over with
> TomEE. :)
> Your thoughts, please.
> Thanks,
> Howard
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
