AFAIR? Jean-Louis, that's funny. Are you telling me that you're not using or testing on 32-bit hardware any longer? :)
On a serious note...what platforms/hardware are TomEE test cases tested on? Do you all test on a 'similar' platform to my 'current' production platform (Windows Server 2003 32bit 4GB RAM)? On Wed, Dec 12, 2012 at 9:44 AM, Jean-Louis MONTEIRO <jeano...@gmail.com>wrote: > 32 Bits = 3,2GB max AFAIR > > > 2012/12/12 Howard W. Smith, Jr. <smithh032...@gmail.com> > > > I really think this is hardware related issue. Why would 64bit 16GB RAM > > development server (2 seconds for 2 emails) out perform 32bit 4GB RAM > > production server (10 minutes for same 2 emails). ? :-) > > > > I am requesting newer better hardware now. > > On Dec 12, 2012 4:21 AM, "Romain Manni-Bucau" <rmannibu...@gmail.com> > > wrote: > > > > > Hi, > > > > > > please reproduce it in a small maven project with a unit test > > > > > > this is tested and we never had such an issue so opening a jira will > > > not help without any sample to reproduce it IMO > > > > > > Romain Manni-Bucau > > > Twitter: @rmannibucau > > > Blog: http://rmannibucau.wordpress.com/ > > > LinkedIn: http://fr.linkedin.com/in/rmannibucau > > > Github: https://github.com/rmannibucau > > > > > > > > > > > > 2012/12/12 Howard W. Smith, Jr. <smithh032...@gmail.com>: > > > > 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 > > > >> > > > >> > > > >> > > > >> On Tue, Dec 11, 2012 at 9:23 PM, Howard W. Smith, Jr. < > > > >> smithh032...@gmail.com> wrote: > > > >> > > > >>> Done. testing now and watching JVM. I need to read that article you > > > >>> shared, so i can learn a bit about heap dump. I see the heap dump > > > button > > > >>> there, but never used it 'yet'. :) > > > >>> > > > >>> > > > >>> On Tue, Dec 11, 2012 at 3:53 PM, Howard W. Smith, Jr. < > > > >>> smithh032...@gmail.com> wrote: > > > >>> > > > >>>> I think I'm going to avoid the single transaction (via single > > > @Stateless > > > >>>> EJB) approach, and use other @Stateless EJBs to make the database > > > table > > > >>>> updates. This approach works everywhere else throughout the web > app. > > > >>>> > > > >>>> I'll just keep the @Stateless EJB for the purpose of being invoked > > by > > > >>>> @Schedule, and it will be the 'driver', and call the > > > >>>> already-defined-and-already-used other @Stateless EJBs that > contain > > > >>>> Persistent context and entity manager to update tables, so this > > > clearly > > > >>>> will be a multiple transaction commit, which should 'not' lock any > > > tables. > > > >>>> :) > > > >>>> > > > >>>> > > > >>>> > > > >>>> On Tue, Dec 11, 2012 at 3:21 PM, Howard W. Smith, Jr. < > > > >>>> smithh032...@gmail.com> wrote: > > > >>>> > > > >>>>> Prior to adding this @Stateless EJB (that's invoked via @Schedule > > > every > > > >>>>> 10 minutes), my JSF web app has been running 100% okay without > any > > > >>>>> deadlocks or anything else like that. > > > >>>>> > > > >>>>> So, is it okay if I just add optimistic locking, em.lock(entity, > > > >>>>> LockType.Optimistic) before any/all em.persist(...) that I have > in > > > the > > > >>>>> @Stateless EJB? > > > >>>>> > > > >>>>> JSF web app is working okay, because the JSF components call > > multiple > > > >>>>> @Stateless EJB that usually do any of the following, SELECT, > > UPDATE, > > > >>>>> DELETE, on one table at time. > > > >>>>> > > > >>>>> > > > >>>>> > > > >>>>> On Tue, Dec 11, 2012 at 2:35 PM, Howard W. Smith, Jr. < > > > >>>>> smithh032...@gmail.com> wrote: > > > >>>>> > > > >>>>>> You're absolutely right, David. Thanks for the response. > > > >>>>>> > > > >>>>>> It is a transaction issue and the @Stateless EJB is holding a > > > >>>>>> transaction open and writing into 6 to 10 tables in a single > > > database, > > > >>>>>> which is also the database accessed by JSF components (by > > > endusers). The > > > >>>>>> @Stateless EJB is on a timer ( @Schedule), checks email server > for > > > incoming > > > >>>>>> requests from customers, and takes that data and inserts it into > > > database, > > > >>>>>> so endusers don't have to manually enter the data (that they > > > receive from > > > >>>>>> these formmail results). > > > >>>>>> > > > >>>>>> Below is the exception that I saw maybe an hour or two ago, and > I > > > >>>>>> confirmed that it's a locking/transaction issue, and from the > > > stacktrace, > > > >>>>>> it seems as though the JSF components cannot access the table, > > that > > > is > > > >>>>>> evidently locked by @Stateless EJB. The @Stateless @EJB updated > > all > > > tables > > > >>>>>> on my faster/dev/test server on average of 1 to 2 seconds, > and/so > > > in my > > > >>>>>> opinion, the data is not that much at all, maybe a few kbytes of > > > data being > > > >>>>>> inserted into the database. Anyway, I've been reading up on > > > pessismistic > > > >>>>>> and optimistic locking, and that's where I was in my reading > > before > > > I > > > >>>>>> noticed your email. I really don't know what the database or JPA > > is > > > >>>>>> defaulting to, because honestly, I have no code that specifies > any > > > locks. > > > >>>>>> Recently, I only added query hint (readonly) to JPA queries. > > > Personally, I > > > >>>>>> feel as though I can use 'no locking' for these inserts, since > > this > > > is > > > >>>>>> brand new data, but the JSF components may be locking the > > > entites/tables > > > >>>>>> during simple queries (SELECT statements). Feel free to change > > this > > > >>>>>> email/topic to a more suitable topic/subject, if necessary. :) > > > >>>>>> > > > >>>>>> > > > >>>>>> > > > >>>>>> > > > >>>> > > > >>> > > > >> > > > > > > > > > -- > Jean-Louis >
