Well, my web app has performed very well with 32bit and 4GB RAM (Glassfish and now via TomEE). I just find it strange that 'insert' operations/transactions via @Stateless EJB triggered by @Schedule method on the @Stateless EJB performs so very slow and locks the database (deadlock situation) on my 32bit 4GB RAM production server, but similar multiple-table update initiated by enduser performs 'very very fast' and 'no' deadlock...ever!!!
So, I'm thinking about redesigning my current implementation, the @Schedule method on @Stateless to import some data (from customer-request emails), and 'instead', present an option on the page (similar to Microsoft Outlook and Outlook Express 'Send/Receive' option, and leave it up to the web app enduser to take time out of his session to invoke the CDI @RequestScoped bean to perform the multiple-table update, and then I think this way, there will be no deadlock situation, since I never see deadlock situation/exception while endusers are logged in completing all kinds of database transactions 'concurrently'. It makes me not trust @Stateless @Schedule (background) transactions, since it completely locks up the database, and at same time, locks up the web app real bad! :( On Wed, Dec 12, 2012 at 11:27 PM, knak55 <naka...@xb4.so-net.ne.jp> wrote: > Thank you, smithh032772, > > The Linux machine where I plan to deploy my application does not have so > much memory (4GB). But the DB size is very small for the present, maybe a > few years. So I will go with 32bit JVM at first. When the DB becomes > bigger, > I will move the system to 64bit environment. > > > > > -- > View this message in context: > http://openejb.979440.n4.nabble.com/DB-access-is-very-slow-tp4659326p4659485.html > Sent from the OpenEJB User mailing list archive at Nabble.com. >
