Howard W. Smith, Jr. created OPENEJB-1968:
---------------------------------------------
Summary: @Stateless EJB with @Schedule method and single
EntityManager/transaction does not perform 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.
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
