Re: TomEE: @Stateless EJB holds transaction/database-locks after @Schedule method completed
And, to add, this is probably not the first time hearing this from me, but I've already gone on and learned and benefited by being active here in the tomee/openejb mailing list (community) now. So...loads of thanks to you guys! On Wed, Dec 12, 2012 at 11:39 AM, Howard W. Smith, Jr. < smithh032...@gmail.com> wrote: > Well, I appreciate it...a lot. The first real open source project that I > really could see the benefit of 'open source' was PrimeFaces. I was very > very active in the forum there as I was developing my JSF web application, > and I saw the value of open source, supporting the 'community', and the > value of issue tracker, filing issues, and even referring to issue tracker > for possible fixes/workarounds...even if the issue/JIRA is not marked as > fixed yet. I have benefited big time from PrimeFaces community, > stackoverflow, and google... in the last year as a 1.5-year-old JAVA/JSF > developer. > > R&D (research and development) has been my job for the last 1.5 years, and > I love it! > > Anyway, i'm glad that TomEE/OpenEJB committers support the (open source) > community as well. I think open source probably improves software the most, > because many 'users' will use open source version, and I 'think' that open > source users are filing or communicating most of the issues... but I could > be wrong... I'm still new at all this. :) > > > > On Wed, Dec 12, 2012 at 11:24 AM, Jean-Louis MONTEIRO > wrote: > >> Thx you to keep interesting even if TomEE is not perfect. We know that and >> we want to make it even better thanks to users feedback. >> >> Regarding responses, almost all of us don't work on opensource and TomEE >> full time. It's mainly our free time and a company contribution when >> possible and when it matches to company business needs. >> >> So we try to share as much as possible our experience and also to get the >> most from user needs, feedback and questions (kinda 2 ways discussion ;-)) >> >> Jean-Louis >> >> >> 2012/12/12 Howard W. Smith, Jr. >> >> > Interesting response, thanks Jean-Louis for the response. I'll keep >> that in >> > mind when I present issues/questions. >> > >> > I'm loving TomEE, especially the committers! thank you all for all your >> > responses...so far! >> > >> > >> > >> > On Wed, Dec 12, 2012 at 11:04 AM, Jean-Louis MONTEIRO < >> jeano...@gmail.com >> > >wrote: >> > >> > > Interesting question :) >> > > I of course still use 32Bits architecture, but was not fully sure of >> the >> > > precise number. >> > > >> > > Anyway, interesting link, thx. >> > > >> > > Regarding TomEE testing. >> > > Most of developers use MacOS and Linux (Ubuntu or so) system. >> > > >> > > In the CI, we are used to focus on Ubuntu but we should have also a >> > > configuration on Windows. Can't remember exactly the link (jenckins >> maybe >> > > instead of buildbot), but I can't retrieve it. >> > > >> > > Some years ago (not sure), we also asked for a virtual machin for >> MacOS. >> > > Finally, I guess we still have a build with an IBM JDK. >> > > >> > > Hope it helps >> > > JLouis >> > > >> > > >> > > >> > > 2012/12/12 Howard W. Smith, Jr. >> > > >> > > > Wow, I wanted to search google, but didn't have to, it was in my >> email >> > > > (oracle java developer email). That was right on time. >> > > > >> > > > http://plumbr.eu/blog/should-i-use-32-or-64-bit-jvm >> > > > >> > > > >> > > > On Wed, Dec 12, 2012 at 9:55 AM, Howard W. Smith, Jr. < >> > > > smithh032...@gmail.com> wrote: >> > > > >> > > > > 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 >> > > > >> >> > > > >> >> > > > >> > > >> > > >> > > >> > > -- >> > > Jean-Louis >> > > >> > >> >> >> >> -- >> Jean-Louis >> > >
Re: TomEE: @Stateless EJB holds transaction/database-locks after @Schedule method completed
Well, I appreciate it...a lot. The first real open source project that I really could see the benefit of 'open source' was PrimeFaces. I was very very active in the forum there as I was developing my JSF web application, and I saw the value of open source, supporting the 'community', and the value of issue tracker, filing issues, and even referring to issue tracker for possible fixes/workarounds...even if the issue/JIRA is not marked as fixed yet. I have benefited big time from PrimeFaces community, stackoverflow, and google... in the last year as a 1.5-year-old JAVA/JSF developer. R&D (research and development) has been my job for the last 1.5 years, and I love it! Anyway, i'm glad that TomEE/OpenEJB committers support the (open source) community as well. I think open source probably improves software the most, because many 'users' will use open source version, and I 'think' that open source users are filing or communicating most of the issues... but I could be wrong... I'm still new at all this. :) On Wed, Dec 12, 2012 at 11:24 AM, Jean-Louis MONTEIRO wrote: > Thx you to keep interesting even if TomEE is not perfect. We know that and > we want to make it even better thanks to users feedback. > > Regarding responses, almost all of us don't work on opensource and TomEE > full time. It's mainly our free time and a company contribution when > possible and when it matches to company business needs. > > So we try to share as much as possible our experience and also to get the > most from user needs, feedback and questions (kinda 2 ways discussion ;-)) > > Jean-Louis > > > 2012/12/12 Howard W. Smith, Jr. > > > Interesting response, thanks Jean-Louis for the response. I'll keep that > in > > mind when I present issues/questions. > > > > I'm loving TomEE, especially the committers! thank you all for all your > > responses...so far! > > > > > > > > On Wed, Dec 12, 2012 at 11:04 AM, Jean-Louis MONTEIRO < > jeano...@gmail.com > > >wrote: > > > > > Interesting question :) > > > I of course still use 32Bits architecture, but was not fully sure of > the > > > precise number. > > > > > > Anyway, interesting link, thx. > > > > > > Regarding TomEE testing. > > > Most of developers use MacOS and Linux (Ubuntu or so) system. > > > > > > In the CI, we are used to focus on Ubuntu but we should have also a > > > configuration on Windows. Can't remember exactly the link (jenckins > maybe > > > instead of buildbot), but I can't retrieve it. > > > > > > Some years ago (not sure), we also asked for a virtual machin for > MacOS. > > > Finally, I guess we still have a build with an IBM JDK. > > > > > > Hope it helps > > > JLouis > > > > > > > > > > > > 2012/12/12 Howard W. Smith, Jr. > > > > > > > Wow, I wanted to search google, but didn't have to, it was in my > email > > > > (oracle java developer email). That was right on time. > > > > > > > > http://plumbr.eu/blog/should-i-use-32-or-64-bit-jvm > > > > > > > > > > > > On Wed, Dec 12, 2012 at 9:55 AM, Howard W. Smith, Jr. < > > > > smithh032...@gmail.com> wrote: > > > > > > > > > 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 > > > > >> > > > > >> > > > > > > > > > > > > > > > > -- > > > Jean-Louis > > > > > > > > > -- > Jean-Louis >
Re: TomEE: @Stateless EJB holds transaction/database-locks after @Schedule method completed
Thx you to keep interesting even if TomEE is not perfect. We know that and we want to make it even better thanks to users feedback. Regarding responses, almost all of us don't work on opensource and TomEE full time. It's mainly our free time and a company contribution when possible and when it matches to company business needs. So we try to share as much as possible our experience and also to get the most from user needs, feedback and questions (kinda 2 ways discussion ;-)) Jean-Louis 2012/12/12 Howard W. Smith, Jr. > Interesting response, thanks Jean-Louis for the response. I'll keep that in > mind when I present issues/questions. > > I'm loving TomEE, especially the committers! thank you all for all your > responses...so far! > > > > On Wed, Dec 12, 2012 at 11:04 AM, Jean-Louis MONTEIRO >wrote: > > > Interesting question :) > > I of course still use 32Bits architecture, but was not fully sure of the > > precise number. > > > > Anyway, interesting link, thx. > > > > Regarding TomEE testing. > > Most of developers use MacOS and Linux (Ubuntu or so) system. > > > > In the CI, we are used to focus on Ubuntu but we should have also a > > configuration on Windows. Can't remember exactly the link (jenckins maybe > > instead of buildbot), but I can't retrieve it. > > > > Some years ago (not sure), we also asked for a virtual machin for MacOS. > > Finally, I guess we still have a build with an IBM JDK. > > > > Hope it helps > > JLouis > > > > > > > > 2012/12/12 Howard W. Smith, Jr. > > > > > Wow, I wanted to search google, but didn't have to, it was in my email > > > (oracle java developer email). That was right on time. > > > > > > http://plumbr.eu/blog/should-i-use-32-or-64-bit-jvm > > > > > > > > > On Wed, Dec 12, 2012 at 9:55 AM, Howard W. Smith, Jr. < > > > smithh032...@gmail.com> wrote: > > > > > > > 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 > > > >> > > > >> > > > > > > > > > > > -- > > Jean-Louis > > > -- Jean-Louis
Re: TomEE: @Stateless EJB holds transaction/database-locks after @Schedule method completed
Interesting response, thanks Jean-Louis for the response. I'll keep that in mind when I present issues/questions. I'm loving TomEE, especially the committers! thank you all for all your responses...so far! On Wed, Dec 12, 2012 at 11:04 AM, Jean-Louis MONTEIRO wrote: > Interesting question :) > I of course still use 32Bits architecture, but was not fully sure of the > precise number. > > Anyway, interesting link, thx. > > Regarding TomEE testing. > Most of developers use MacOS and Linux (Ubuntu or so) system. > > In the CI, we are used to focus on Ubuntu but we should have also a > configuration on Windows. Can't remember exactly the link (jenckins maybe > instead of buildbot), but I can't retrieve it. > > Some years ago (not sure), we also asked for a virtual machin for MacOS. > Finally, I guess we still have a build with an IBM JDK. > > Hope it helps > JLouis > > > > 2012/12/12 Howard W. Smith, Jr. > > > Wow, I wanted to search google, but didn't have to, it was in my email > > (oracle java developer email). That was right on time. > > > > http://plumbr.eu/blog/should-i-use-32-or-64-bit-jvm > > > > > > On Wed, Dec 12, 2012 at 9:55 AM, Howard W. Smith, Jr. < > > smithh032...@gmail.com> wrote: > > > > > 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 > > >> > > >> > > > > > > -- > Jean-Louis >
Re: TomEE: @Stateless EJB holds transaction/database-locks after @Schedule method completed
Interesting question :) I of course still use 32Bits architecture, but was not fully sure of the precise number. Anyway, interesting link, thx. Regarding TomEE testing. Most of developers use MacOS and Linux (Ubuntu or so) system. In the CI, we are used to focus on Ubuntu but we should have also a configuration on Windows. Can't remember exactly the link (jenckins maybe instead of buildbot), but I can't retrieve it. Some years ago (not sure), we also asked for a virtual machin for MacOS. Finally, I guess we still have a build with an IBM JDK. Hope it helps JLouis 2012/12/12 Howard W. Smith, Jr. > Wow, I wanted to search google, but didn't have to, it was in my email > (oracle java developer email). That was right on time. > > http://plumbr.eu/blog/should-i-use-32-or-64-bit-jvm > > > On Wed, Dec 12, 2012 at 9:55 AM, Howard W. Smith, Jr. < > smithh032...@gmail.com> wrote: > > > 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 >wrote: > > > >> 32 Bits = 3,2GB max AFAIR > >> > >> > -- Jean-Louis
Re: TomEE: @Stateless EJB holds transaction/database-locks after @Schedule method completed
Wow, I wanted to search google, but didn't have to, it was in my email (oracle java developer email). That was right on time. http://plumbr.eu/blog/should-i-use-32-or-64-bit-jvm On Wed, Dec 12, 2012 at 9:55 AM, Howard W. Smith, Jr. < smithh032...@gmail.com> wrote: > 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 > wrote: > >> 32 Bits = 3,2GB max AFAIR >> >>
Re: TomEE: @Stateless EJB holds transaction/database-locks after @Schedule method completed
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 wrote: > 32 Bits = 3,2GB max AFAIR > > > 2012/12/12 Howard W. Smith, Jr. > > > 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" > > 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. : > > > > 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
Re: TomEE: @Stateless EJB holds transaction/database-locks after @Schedule method completed
32 Bits = 3,2GB max AFAIR 2012/12/12 Howard W. Smith, Jr. > 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" > 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. : > > > 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
Re: TomEE: @Stateless EJB holds transaction/database-locks after @Schedule method completed
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" 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. : > > 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
Re: TomEE: @Stateless EJB holds transaction/database-locks after @Schedule method completed
smiling... okay, well, i already opened the JIRA https://issues.apache.org/jira/browse/OPENEJB-1968 only provided log and @Stateless EJB. On Wed, Dec 12, 2012 at 4:20 AM, Romain Manni-Bucau 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. : > > 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 'personn
Re: TomEE: @Stateless EJB holds transaction/database-locks after @Schedule method completed
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. : > 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 w
