[
https://issues.apache.org/jira/browse/OPENEJB-1968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13530702#comment-13530702
]
Howard W. Smith, Jr. commented on OPENEJB-1968:
-----------------------------------------------
Romain, I think this is hardware-related and I don't think you all have a test
environment (Windows 2003 32bit 4GB RAM server/machine) to duplicate this
situation/exception/etc...
I got a bit farther with this issue, since I changed the implementation (a
little bit). Anyway, my current implementation completes 1 email, which can
contain a maximum of 2 separate customer/purchase orders to insert into the
database via CDI @RequestScoped which is injected by @Stateless bean with
@Schedule on it, BUT, the transaction (of the 2 customer/purchase orders) is
rolling back because of the exception below... :(
INFO: EmailStatelessBean.processAirportShuttleRequest(): ADD Airport Shuttle -
Flight # 1 SUCCESSFULLY for 01/06/2013
Dec 12, 2012 6:33:47 PM pf.ApplicationScopeBean log
INFO: EmailStatelessBean.processAirportShuttleRequest(): ADD Airport Shuttle -
Flight # 2 SUCCESSFULLY for 01/18/2012
Dec 12, 2012 6:33:57 PM 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
> @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
