[
https://issues.apache.org/jira/browse/OPENEJB-1968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13532034#comment-13532034
]
Howard W. Smith, Jr. commented on OPENEJB-1968:
-----------------------------------------------
Okay, not waiting anymore... it's taking too long to insert the 2nd airport
shuttle on Windows Server 2003 32bit machine. I'm going to bring down the
server and comment out the @Schedule for now...since this is production server.
> @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.
> <smithh032...@gmail.com> 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
