[OPENEJB-1968] @Stateless EJB with @Schedule method and single EntityManager/transaction does not perform well and holds transaction

• Type: Bug
• Status: Closed
• Priority: Major
• Resolution: Not A Problem
• Affects Version/s: 4.5.0
• Component/s: ejb31
• Labels: @Stateless EJB entitymanager transaction
• Environment: TomEE 1.5.1; Windows Server 2003 32bit 4GB RAM
• Assignee: Unassigned
• Reporter: Howard W. Smith, Jr.
• Created: 12/Dec/12 09:22
• Updated: 07/Apr/13 17:42
• Resolved: 07/Apr/13 17:42

Description

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. <[e-mail]> 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