Where is your database, localhost? El dic 13, 2012 12:27 AM, "Romain Manni-Bucau" <rmannibu...@gmail.com> escribió:
> Do you have the machine usage (cpu+mem+io)? > > Glassfish is not faster, eclipselink is not faster in general (depend what > you do). Maybe you need to configure openjpa sequence to set bigger > allocation size (openjpa.Sequence=class-tacle(Increment=1000) IIRC) > Le 13 déc. 2012 06:18, "Howard W. Smith, Jr." <smithh032...@gmail.com> a > écrit : > > > 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. > > > > > >
