You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomee.apache.org by knak55 <na...@xb4.so-net.ne.jp> on 2012/12/10 07:34:30 UTC
DB access is very slow
Whenever my application access to DB through JPA on TomEE 1.5, it takes a lot
of time to complete. However, when I deploy the same war file to Glassfish
3.1.2.2, the DB access is very fast.
For example, when I try to update an instance like the following,
-----
mergedA = em.merge(a);
em.flush();
-----
it takes about from 600msec to 800mesec on my desktop.
When I try to insert an instance like the following,
----
em.persist(a);
em.flush();
-----
it takes about from 300msec to 400msec.
When I try to insert two class instances which have relation each other and
one of the class instances has relations with two another class instance
like the following,
-----
A a = em.find(A.class, aId);
B b = em.find(B.class, bId);
C c = new C();
c.setAttribute1(a1);
c.setA(a);
c.setB(b);
a.addC(c);
b.addC(c);
D d = new D();
d.setAttribute1(a1);
d.setC(c);
em.persist(d);
----
it takes about from 1800 - 2100 msec.
However when I try to do the same thing with the same war on the Glassfish
and the same DB, it takes almost 0 msec for all cases. I do not know why
TomEE takes such a long time to do the same things.
Is there anything I can do for improving the TomEE's DB access performance?
Incidentally I used the System.currentTimeMillis() to measure the elapsed
times for each case.
--
View this message in context: http://openejb.979440.n4.nabble.com/DB-access-is-very-slow-tp4659326.html
Sent from the OpenEJB User mailing list archive at Nabble.com.
Re: DB access is very slow
Posted by Romain Manni-Bucau <rm...@gmail.com>.
What's your db config? Did you activate statement cache? Please check
through jmx (jdbcinterceptors attribute, the datasource should be in
openejb mbeans)
Le 11 déc. 2012 02:59, "knak55" <na...@xb4.so-net.ne.jp> a écrit :
> Thank you for your reply, Romain.
>
> I use eclipselink for Glassfish and OpenJPA for TomEE.
> Though I tried to change the application to use the Built Time Enhancement
> for the OpenJPA on TomEE, it does not seem to change much in terms of the
> performance.
> I am not familiar with the Enhancement feature of the OpenJPA, but as I was
> able to see the following lines in the eclipse console, I think the
> Enhancement must have been weaved to Entity classes.
> default INFO [main] openjpa.Tool - Enhancer running on type "class A".
> default INFO [main] openjpa.Tool - Enhancer running on type "class B".
> default INFO [main] openjpa.Tool - Enhancer running on type "class C".
> default INFO [main] openjpa.Tool - Enhancer running on type "class D".
>
> Incidentally each DB access call is done in a Stateless Session Bean.
>
> If there is anything I can do, please let me know.
>
>
>
> --
> View this message in context:
> http://openejb.979440.n4.nabble.com/DB-access-is-very-slow-tp4659326p4659382.html
> Sent from the OpenEJB User mailing list archive at Nabble.com.
>
Re: DB access is very slow
Posted by "Howard W. Smith, Jr." <sm...@gmail.com>.
hahaha, it is funny. :)
i will definitely consider another database, thanks.
On Thu, Dec 13, 2012 at 12:08 PM, Romain Manni-Bucau
<rm...@gmail.com>wrote:
> funny what you call fast sounds slow for me :p
>
>
> that's said maybe try antoher database (mysql?)
>
Re: DB access is very slow
Posted by Romain Manni-Bucau <rm...@gmail.com>.
funny what you call fast sounds slow for me :p
that's said maybe try antoher database (mysql?)
maybe the openjpa dictionnary is bad (maybe ask openjpa btw)
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau
2012/12/13 Howard W. Smith, Jr. <sm...@gmail.com>:
> 1. In a .zip file, the Derby database is at least 17MB
>
> 2. yes, have indexes, i did that months ago after reviewing the apache
> derby tuning database PDF
>
> 3. trust me, it is lightning fast when the 'norm' code is performing
> database operations, concurrently; 'norm' code/approach = managed beans
> have @EJB, @EJB = DAO
>
> 4. the approach discussed in this email thread and other-related email
> threads, I did an outside-of-the-norm approach for my app
>
> 5. outside-of-the-norm approach = @Stateless EJB with @Schedule method()
> calls multiple @Stateless EJBs (DAO) to lookup as well as simple
> insert/persist statements
>
> 6. lightning fast? the outside-of-the-norm approach takes 1 or 2 seconds on
> Windows Server 2008 64-bit 16GB RAM server
>
> 7. outside-of-the-norm appraoch takes 10 minutes on Windows Server 2003
> 32-bit 4GB RAM server
>
> 8. i consider Apache Derby a real DB while others may not. I've seen
> benchmarks, and what I saw, Derby outperforms MySQL; only other DB that I
> would be interested in migrating to... is HSQL DB (hyper SQL DB); i think
> that's the one shipped with our beloved 'TomEE'... Derby has
> excellent/perfect documentation and i am very impressed with the
> performance of Derby on the Windows Server 2003 32-bit 4GB
>
> 9. 'norm' concurrent operations in my app performed very well for months
> with JSF-managed-beans on Glassfish 3.1.2.2, and the same 'norm' concurrent
> operations in my app is performing just as well now (maybe faster) on TomEE
> (CDI-managed-beans instead of JSF managed beans)
>
> 10. yes, i heard/know that people like to consider Apache Derby a testing
> database, but it's definitely my production database...performing very very
> well and very reliable; honestly, i would only replace it for even better
> performance; most of my 'norm' concurrent operations take 2 to 3 seconds;
> user don't have to wait long at all unless i'm retrieving a bunch of rows
> with some complicated joins involved, oh, and then the container has to
> 'render' that data (when user selects plenty of data from database); and we
> know that rendering can hinder performance. I found that out when i
> migrated from glassfish to tomee... had to eliminate many of the
> rendered="..." on the popular/frequently-used xhtml pages in the app. :)
>
>
> On Thu, Dec 13, 2012 at 11:27 AM, Neale <ne...@metawerx.net> wrote:
>
>> How big is the DB?
>> Do you have indexes?
>> It should be lightning fast (1000+ requests per minute) for small DB
>> name/address lookups.
>> Have you tried a real DB like MariaDB/MySQL/PgSQL? Derby is pretty
>> terrible if the database is substantial... good for testing small projects
>> though.
>>
Re: DB access is very slow
Posted by "Howard W. Smith, Jr." <sm...@gmail.com>.
Great, thanks Romain. Is MySQL still Open Source? I thought they are under
Oracle umbrella now...and I would assume there is a license or fee
involved. right?
On Thu, Dec 13, 2012 at 1:20 PM, Romain Manni-Bucau
<rm...@gmail.com>wrote:
> MySQL, don't even try hsqldb if your app has users
>
> then http://dbcopyplugin.sourceforge.net/ should help ;)
>
Re: DB access is very slow
Posted by "Howard W. Smith, Jr." <sm...@gmail.com>.
okay, thanks!
On Thu, Dec 13, 2012 at 1:26 PM, José Luis Cetina <ma...@gmail.com>wrote:
> I recommend to you Mysql too. I always used with jpa openjpa or
> eclipselink for now without problems.
>
Re: DB access is very slow
Posted by José Luis Cetina <ma...@gmail.com>.
I recommend to you Mysql too. I always used with jpa openjpa or
eclipselink for now without problems.
El dic 13, 2012 12:21 PM, "Romain Manni-Bucau" <rm...@gmail.com>
escribió:
> MySQL, don't even try hsqldb if your app has users
>
> then http://dbcopyplugin.sourceforge.net/ should help ;)
>
> Romain Manni-Bucau
> Twitter: @rmannibucau
> Blog: http://rmannibucau.wordpress.com/
> LinkedIn: http://fr.linkedin.com/in/rmannibucau
> Github: https://github.com/rmannibucau
>
>
>
> 2012/12/13 Howard W. Smith, Jr. <sm...@gmail.com>:
> > Neale,
> >
> > Thanks for the responses and suggestions; much appreciated.
> >
> > I will definitely consider another database. I need to take some time and
> > dump all of the 'real' data (and the schema), and make sure the SQL and
> > schema will work well with a 'real' database. For the most part, it is
> all
> > SQL-92, except for Derby SQL for the identity fields for primary key
> > columns on 99% of the tables in the database.
> >
> > Please feel free to send me a URL to a blog or two for migrating from
> derby
> > to one of the 'real' databases. Also, send me a URL to recommended 'real'
> > databases. MySQL and HyperSQL DB is within my radar right now.
> >
> > Thanks,
> > Howard
> >
> >
> > On Thu, Dec 13, 2012 at 12:50 PM, Neale <ne...@metawerx.net> wrote:
> >
> >> Hi Howard,
> >>
> >> Derby is an in-memory java-based DB, so with a 100mb database it
> performs
> >> great.
> >>
> >> Once you start putting real data into it, it fails horribly. It's
> >> designed for testing, and never for production (read the docs).
> >>
> >> Please never use it as a "production" database. We had a customer here
> >> using it, and after their database grew to 2gb in size it started
> consuming
> >> 100% CPU on multiple CPUs and displaying huge disk I/O and GC. They
> >> converted to MySQL and their usage has dropped to less than 1% of what
> >> derby was using.
> >>
> >> But it's a great DB for testing small apps, and with very small apps it
> >> may even perform faster than a real DB ;-)
> >>
> >> Anyway, with your specific problem, for now I would recommend separating
> >> the database and JPA so you can measure them both separately.
> >>
> >> It's always easier to solve a problem by breaking it into smaller
> pieces.
> >>
> >> Best Regards,
> >> Neale Rudd
> >> Metawerx Pty Ltd
> >> www.metawerx.net
> >>
>
Re: DB access is very slow
Posted by Romain Manni-Bucau <rm...@gmail.com>.
MySQL, don't even try hsqldb if your app has users
then http://dbcopyplugin.sourceforge.net/ should help ;)
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau
2012/12/13 Howard W. Smith, Jr. <sm...@gmail.com>:
> Neale,
>
> Thanks for the responses and suggestions; much appreciated.
>
> I will definitely consider another database. I need to take some time and
> dump all of the 'real' data (and the schema), and make sure the SQL and
> schema will work well with a 'real' database. For the most part, it is all
> SQL-92, except for Derby SQL for the identity fields for primary key
> columns on 99% of the tables in the database.
>
> Please feel free to send me a URL to a blog or two for migrating from derby
> to one of the 'real' databases. Also, send me a URL to recommended 'real'
> databases. MySQL and HyperSQL DB is within my radar right now.
>
> Thanks,
> Howard
>
>
> On Thu, Dec 13, 2012 at 12:50 PM, Neale <ne...@metawerx.net> wrote:
>
>> Hi Howard,
>>
>> Derby is an in-memory java-based DB, so with a 100mb database it performs
>> great.
>>
>> Once you start putting real data into it, it fails horribly. It's
>> designed for testing, and never for production (read the docs).
>>
>> Please never use it as a "production" database. We had a customer here
>> using it, and after their database grew to 2gb in size it started consuming
>> 100% CPU on multiple CPUs and displaying huge disk I/O and GC. They
>> converted to MySQL and their usage has dropped to less than 1% of what
>> derby was using.
>>
>> But it's a great DB for testing small apps, and with very small apps it
>> may even perform faster than a real DB ;-)
>>
>> Anyway, with your specific problem, for now I would recommend separating
>> the database and JPA so you can measure them both separately.
>>
>> It's always easier to solve a problem by breaking it into smaller pieces.
>>
>> Best Regards,
>> Neale Rudd
>> Metawerx Pty Ltd
>> www.metawerx.net
>>
Re: DB access is very slow
Posted by "Howard W. Smith, Jr." <sm...@gmail.com>.
Thanks Will!
On Thu, Dec 13, 2012 at 1:41 PM, Will Hoover <ja...@gmail.com> wrote:
> If you want speed/performance/flexibility/scalability I would recommend H2
> Database:
>
> http://www.h2database.com
>
> There's a really handy comparison matrix (Derby/HSQLDB/MySQL/PostgreSQL):
>
> http://www.h2database.com/html/features.html#comparison
>
> The nice thing about H2 Database is it can potentially simplify migration
> by
> using the available compatibility modes
> (DB2/Derby/HSQLDB/MSSQL/MySQL/Oracle/PostgreSQL):
>
> http://www.h2database.com/html/features.html#compatibility
>
RE: DB access is very slow
Posted by Will Hoover <ja...@gmail.com>.
If you want speed/performance/flexibility/scalability I would recommend H2
Database:
http://www.h2database.com
There's a really handy comparison matrix (Derby/HSQLDB/MySQL/PostgreSQL):
http://www.h2database.com/html/features.html#comparison
The nice thing about H2 Database is it can potentially simplify migration by
using the available compatibility modes
(DB2/Derby/HSQLDB/MSSQL/MySQL/Oracle/PostgreSQL):
http://www.h2database.com/html/features.html#compatibility
-----Original Message-----
From: Howard W. Smith, Jr. [mailto:smithh032772@gmail.com]
Sent: Thursday, December 13, 2012 1:18 PM
To: users@openejb.apache.org
Subject: Re: DB access is very slow
Neale,
Thanks for the responses and suggestions; much appreciated.
I will definitely consider another database. I need to take some time and
dump all of the 'real' data (and the schema), and make sure the SQL and
schema will work well with a 'real' database. For the most part, it is all
SQL-92, except for Derby SQL for the identity fields for primary key columns
on 99% of the tables in the database.
Please feel free to send me a URL to a blog or two for migrating from derby
to one of the 'real' databases. Also, send me a URL to recommended 'real'
databases. MySQL and HyperSQL DB is within my radar right now.
Thanks,
Howard
On Thu, Dec 13, 2012 at 12:50 PM, Neale <ne...@metawerx.net> wrote:
> Hi Howard,
>
> Derby is an in-memory java-based DB, so with a 100mb database it
> performs great.
>
> Once you start putting real data into it, it fails horribly. It's
> designed for testing, and never for production (read the docs).
>
> Please never use it as a "production" database. We had a customer
> here using it, and after their database grew to 2gb in size it started
> consuming 100% CPU on multiple CPUs and displaying huge disk I/O and
> GC. They converted to MySQL and their usage has dropped to less than
> 1% of what derby was using.
>
> But it's a great DB for testing small apps, and with very small apps
> it may even perform faster than a real DB ;-)
>
> Anyway, with your specific problem, for now I would recommend
> separating the database and JPA so you can measure them both separately.
>
> It's always easier to solve a problem by breaking it into smaller pieces.
>
> Best Regards,
> Neale Rudd
> Metawerx Pty Ltd
> www.metawerx.net
>
Re: DB access is very slow
Posted by "Howard W. Smith, Jr." <sm...@gmail.com>.
Neale,
Thanks for the responses and suggestions; much appreciated.
I will definitely consider another database. I need to take some time and
dump all of the 'real' data (and the schema), and make sure the SQL and
schema will work well with a 'real' database. For the most part, it is all
SQL-92, except for Derby SQL for the identity fields for primary key
columns on 99% of the tables in the database.
Please feel free to send me a URL to a blog or two for migrating from derby
to one of the 'real' databases. Also, send me a URL to recommended 'real'
databases. MySQL and HyperSQL DB is within my radar right now.
Thanks,
Howard
On Thu, Dec 13, 2012 at 12:50 PM, Neale <ne...@metawerx.net> wrote:
> Hi Howard,
>
> Derby is an in-memory java-based DB, so with a 100mb database it performs
> great.
>
> Once you start putting real data into it, it fails horribly. It's
> designed for testing, and never for production (read the docs).
>
> Please never use it as a "production" database. We had a customer here
> using it, and after their database grew to 2gb in size it started consuming
> 100% CPU on multiple CPUs and displaying huge disk I/O and GC. They
> converted to MySQL and their usage has dropped to less than 1% of what
> derby was using.
>
> But it's a great DB for testing small apps, and with very small apps it
> may even perform faster than a real DB ;-)
>
> Anyway, with your specific problem, for now I would recommend separating
> the database and JPA so you can measure them both separately.
>
> It's always easier to solve a problem by breaking it into smaller pieces.
>
> Best Regards,
> Neale Rudd
> Metawerx Pty Ltd
> www.metawerx.net
>
Re: DB access is very slow
Posted by Romain Manni-Bucau <rm...@gmail.com>.
profile just this part :p (without front etc)
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau
2012/12/13 Howard W. Smith, Jr. <sm...@gmail.com>:
> Sorry, don't understand what you're trying to say here.
>
> @Schedule is used to poll or check an email server for 'specific' emails,
> and the emails of interest has JSON embedded, and that JSON are populated
> into POJOs via Gson, and then the fun begins... saving that little bit of
> data to multiple tables... so endusers don't have to perform 'data entry'
> and enter that data 'manually'.
>
> 1. The design and implemenation... works as designed
>
> 2. the @Stateless EJB with @Schedule getEmails().. works as designed
>
> 3. @Stateless EJB (DAO) updating the database.. works as designed but takes
> toooo long.
>
> You all say it is because of the database, but I actually disagree it is
> the database, because user click button, CDI-managed-bean updating database
> via @Stateless EJB (DAO) is much much faster than #3 listed above.
>
>
> On Thu, Dec 13, 2012 at 2:37 PM, Romain Manni-Bucau
> <rm...@gmail.com>wrote:
>
>> well your @Schedule == polling no server, it sounds weird by design
Re: DB access is very slow
Posted by "Howard W. Smith, Jr." <sm...@gmail.com>.
Sorry, don't understand what you're trying to say here.
@Schedule is used to poll or check an email server for 'specific' emails,
and the emails of interest has JSON embedded, and that JSON are populated
into POJOs via Gson, and then the fun begins... saving that little bit of
data to multiple tables... so endusers don't have to perform 'data entry'
and enter that data 'manually'.
1. The design and implemenation... works as designed
2. the @Stateless EJB with @Schedule getEmails().. works as designed
3. @Stateless EJB (DAO) updating the database.. works as designed but takes
toooo long.
You all say it is because of the database, but I actually disagree it is
the database, because user click button, CDI-managed-bean updating database
via @Stateless EJB (DAO) is much much faster than #3 listed above.
On Thu, Dec 13, 2012 at 2:37 PM, Romain Manni-Bucau
<rm...@gmail.com>wrote:
> well your @Schedule == polling no server, it sounds weird by design
Re: DB access is very slow
Posted by Neale <ne...@metawerx.net>.
Hi Romain,
Ah ok that makes sense. I'm still fairly new to EE thinking ;-)
So if I deploy a new TomEE app, I should use JTA and modify tomee.xml to use
my DB descriptor - not the Tomcat method of context.xml?
Is this the best doc page on how to configure it?
http://tomee.apache.org/containers-and-resources.html
Is there another page which just shows how to get a simple database-app
working with JTA on TomEE? That would be really helpful I think, as most
users want to do exactly that.
Or an example simple DB app in the examples section?
Best Regards,
Neale
----- Original Message -----
From: "Romain Manni-Bucau" <rm...@gmail.com>
To: <us...@openejb.apache.org>
Sent: Friday, December 14, 2012 6:37 AM
Subject: Re: DB access is very slow
> well your @Schedule == polling no server, it sounds weird by design
>
> @Neale: the default datasource will be a feature of JavaEE 7.
> Context.xml stuff should be better on 1.5.1 but we clearly use
> tomee.xml by default (and not context.xml) because of jta management
> at least
>
> that's said the issues are often easier, often the non jt datasource
> is not defined or something like that
>
> Romain Manni-Bucau
> Twitter: @rmannibucau
> Blog: http://rmannibucau.wordpress.com/
> LinkedIn: http://fr.linkedin.com/in/rmannibucau
> Github: https://github.com/rmannibucau
>
>
>
> 2012/12/13 Howard W. Smith, Jr. <sm...@gmail.com>:
>> Honestly, my preference would be to use @Schedule; I don't want to bug
>> the
>> users and ask/make/require them to click a button to download this data
>> from email server. TomEE examples has @Schedule on a Singleton bean (I
>> think that's what I remember, when I saw it). I saw the same in a
>> (BalusC)
>> stackoverflow answer. To this day, I have never used Singleton bean. I
>> assumed that since I have a CDI @ApplicationScoped bean, then there
>> should
>> be no 'need' to use Singleton bean. Singleton and ApplicationScoped are
>> both application wide, but now via CDI, it seems as though any/everything
>> is application-wide, available within any 'context'.
>>
>> I can accept the notion that my design/implementation is wrong. I've
>> already learned how to 'improve' my app, specifically for TomEE as the
>> container, where the app ran perfectly/flawlessly/reliably in Glassfish
>> (and I'm not alone for saying that).
>>
>> I'm rewriting code right now, trying to make sure the transaction(s) are
>> as
>> short as possible. Originally, the code was written similar to a batch
>> process (kinda like the java application I wrote... to migrate data from
>> dBase IV to the newer/bigger JavaDB... I went from 6-table dbase IV
>> database to 88+ table JavaDB).
>>
>> As far as the code sample... David Blevins shared that in another thread.
>> I
>> may have to dig that up.
>>
>>
>> On Thu, Dec 13, 2012 at 2:16 PM, Romain Manni-Bucau
>> <rm...@gmail.com>wrote:
>>
>>> Well Howard think you should try to share with us some sample (not the
>>> full app please)
>>>
>>> i used a lot Geronimo transaction manager and i used ( a bit less)
>>> @Schedule and it worked fine
>>>
>>> i could understand OpenJPA begin slower on derby but geronimo not
>>> working is a different topic
>>>
>>> Side note: maybe your design is wrong, you manage a history in a
>>> @Schedule? not sure that's the best you can do
>>>
Re: DB access is very slow
Posted by "Howard W. Smith, Jr." <sm...@gmail.com>.
Interesting what you mentioned about JavaEE7, I remember you advising me to
use tomee.xml and even 'questioned' me... why are you not using tomee.xml
instead of context.xml... remember that? :)
Well, I'm definitely using JTA, and if I understand you correctly, I think
you are recommending to remove non-jta from my persistence.xml as well as
tomee.xml. Right?
On Thu, Dec 13, 2012 at 2:37 PM, Romain Manni-Bucau
<rm...@gmail.com>wrote:
> well your @Schedule == polling no server, it sounds weird by design
>
> @Neale: the default datasource will be a feature of JavaEE 7.
> Context.xml stuff should be better on 1.5.1 but we clearly use
> tomee.xml by default (and not context.xml) because of jta management
> at least
>
> that's said the issues are often easier, often the non jt datasource
> is not defined or something like that
>
Re: DB access is very slow
Posted by Romain Manni-Bucau <rm...@gmail.com>.
well your @Schedule == polling no server, it sounds weird by design
@Neale: the default datasource will be a feature of JavaEE 7.
Context.xml stuff should be better on 1.5.1 but we clearly use
tomee.xml by default (and not context.xml) because of jta management
at least
that's said the issues are often easier, often the non jt datasource
is not defined or something like that
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau
2012/12/13 Howard W. Smith, Jr. <sm...@gmail.com>:
> Honestly, my preference would be to use @Schedule; I don't want to bug the
> users and ask/make/require them to click a button to download this data
> from email server. TomEE examples has @Schedule on a Singleton bean (I
> think that's what I remember, when I saw it). I saw the same in a (BalusC)
> stackoverflow answer. To this day, I have never used Singleton bean. I
> assumed that since I have a CDI @ApplicationScoped bean, then there should
> be no 'need' to use Singleton bean. Singleton and ApplicationScoped are
> both application wide, but now via CDI, it seems as though any/everything
> is application-wide, available within any 'context'.
>
> I can accept the notion that my design/implementation is wrong. I've
> already learned how to 'improve' my app, specifically for TomEE as the
> container, where the app ran perfectly/flawlessly/reliably in Glassfish
> (and I'm not alone for saying that).
>
> I'm rewriting code right now, trying to make sure the transaction(s) are as
> short as possible. Originally, the code was written similar to a batch
> process (kinda like the java application I wrote... to migrate data from
> dBase IV to the newer/bigger JavaDB... I went from 6-table dbase IV
> database to 88+ table JavaDB).
>
> As far as the code sample... David Blevins shared that in another thread. I
> may have to dig that up.
>
>
> On Thu, Dec 13, 2012 at 2:16 PM, Romain Manni-Bucau
> <rm...@gmail.com>wrote:
>
>> Well Howard think you should try to share with us some sample (not the
>> full app please)
>>
>> i used a lot Geronimo transaction manager and i used ( a bit less)
>> @Schedule and it worked fine
>>
>> i could understand OpenJPA begin slower on derby but geronimo not
>> working is a different topic
>>
>> Side note: maybe your design is wrong, you manage a history in a
>> @Schedule? not sure that's the best you can do
>>
Re: DB access is very slow
Posted by "Howard W. Smith, Jr." <sm...@gmail.com>.
Honestly, my preference would be to use @Schedule; I don't want to bug the
users and ask/make/require them to click a button to download this data
from email server. TomEE examples has @Schedule on a Singleton bean (I
think that's what I remember, when I saw it). I saw the same in a (BalusC)
stackoverflow answer. To this day, I have never used Singleton bean. I
assumed that since I have a CDI @ApplicationScoped bean, then there should
be no 'need' to use Singleton bean. Singleton and ApplicationScoped are
both application wide, but now via CDI, it seems as though any/everything
is application-wide, available within any 'context'.
I can accept the notion that my design/implementation is wrong. I've
already learned how to 'improve' my app, specifically for TomEE as the
container, where the app ran perfectly/flawlessly/reliably in Glassfish
(and I'm not alone for saying that).
I'm rewriting code right now, trying to make sure the transaction(s) are as
short as possible. Originally, the code was written similar to a batch
process (kinda like the java application I wrote... to migrate data from
dBase IV to the newer/bigger JavaDB... I went from 6-table dbase IV
database to 88+ table JavaDB).
As far as the code sample... David Blevins shared that in another thread. I
may have to dig that up.
On Thu, Dec 13, 2012 at 2:16 PM, Romain Manni-Bucau
<rm...@gmail.com>wrote:
> Well Howard think you should try to share with us some sample (not the
> full app please)
>
> i used a lot Geronimo transaction manager and i used ( a bit less)
> @Schedule and it worked fine
>
> i could understand OpenJPA begin slower on derby but geronimo not
> working is a different topic
>
> Side note: maybe your design is wrong, you manage a history in a
> @Schedule? not sure that's the best you can do
>
Re: DB access is very slow
Posted by Neale <ne...@metawerx.net>.
Actually I'd recommend removing the default HSQLDB reference in tomee.xml
I'm not sure if it's used for one of the examples or what it's used for, but
every time I"ve deployed a TomEE instance I've had to remove/disable it
manually because it overrides my real database definition
(META-INF/context.xml)
If it's used for something, maybe that should be documented somewhere? Or
otherwise maybe the release versions of TomEE can include it, but maybe have
it commented out?
Best Regards,
Neale
----- Original Message -----
From: "Romain Manni-Bucau" <rm...@gmail.com>
To: <us...@openejb.apache.org>
Sent: Friday, December 14, 2012 6:16 AM
Subject: Re: DB access is very slow
> hard to come back now ;)
>
> back on the topic,
>
> Well Howard think you should try to share with us some sample (not the
> full app please)
>
> i used a lot Geronimo transaction manager and i used ( a bit less)
> @Schedule and it worked fine
>
> i could understand OpenJPA begin slower on derby but geronimo not
> working is a different topic
>
> Side note: maybe your design is wrong, you manage a history in a
> @Schedule? not sure that's the best you can do
>
> Romain Manni-Bucau
> Twitter: @rmannibucau
> Blog: http://rmannibucau.wordpress.com/
> LinkedIn: http://fr.linkedin.com/in/rmannibucau
> Github: https://github.com/rmannibucau
>
>
>
> 2012/12/13 Neale <ne...@metawerx.net>:
>> Romain is great :-)
>>
>>
>> ----- Original Message ----- From: "Howard W. Smith, Jr."
>> <sm...@gmail.com>
>> To: <us...@openejb.apache.org>
>> Sent: Friday, December 14, 2012 6:09 AM
>>
>> Subject: Re: DB access is very slow
>>
>>
>>> Thank you very much Neale for all your responses. I have been open to
>>> searching around for a good java web host, but just didn't find it
>>> necessary...yet. At some point, I may be interested in your TomEE
>>> hosting
>>> service; when the project reaches a larger scope of endusers. Right now,
>>> I
>>> think we are doing okay with the hardware in place (and planning to have
>>> in
>>> place).
>>>
>>> I'll do my best to take any/all of your suggestions...especially about
>>> high
>>> volume. Romain is funny...he seems to welcome any/all discussion related
>>> to
>>> 'using TomEE'. :)
>>>
>>>
>>> On Thu, Dec 13, 2012 at 2:04 PM, Neale <ne...@metawerx.net> wrote:
>>>
>>>> Hi Howard,
>>>>
>>>> Your discussions are very interesting - I haven't unsubscribed from the
>>>> TomEE list yet even though there is such high volume. Lately I
>>>> actually
>>>> quite enjoy following your progress. There are a lot of emails - but
>>>> just
>>>> don't get too off-topic ;-) Try a few things on your own, then bring
>>>> your
>>>> findings to the list. Some questions are a bit off-topic so they're
>>>> better
>>>> being discussed on other lists.
>>>>
>>>> It's really exciting seeing you using TomEE for the first time and
>>>> running
>>>> into the initial problems. Those problems are very interesting. When
>>>> we
>>>> get to discussing Derby vs Hyper vs MySQL however, it's better to do
>>>> some
>>>> independant research and come back to the list afterwards. (IMHO)
>>>>
>>>> Anyway - I'd love to hear more about how your project turns out, and if
>>>> you want some free hosting on our new TomEE cluster, drop me a private
>>>> email and I'd be happy to give you some free space. Any experience we
>>>> have
>>>> with commerical TomEE customers is a great experience for us that we
>>>> can
>>>> blog about or share with the TomEE devs.
>>>>
>>>> Best Regards,
>>>> Neale
>>>>
>>>>
>>>>
>>>> ----- Original Message ----- From: "Howard W. Smith, Jr." <
>>>> smithh032772@gmail.com>
>>>> To: <us...@openejb.apache.org>
>>>> Sent: Friday, December 14, 2012 5:50 AM
>>>>
>>>> Subject: Re: DB access is very slow
>>>>
>>>>
>>>> Agreed about Romain, he is very amazing. Noted about HyperSQL, will
>>>> avoid
>>>>>
>>>>> that, and understood about 17mb = "playing". This is a new app that
>>>>> I've
>>>>> developed and it's being used every day for 'business', so definitely
>>>>> not
>>>>> playing, but I do want to move to prime-time and a faster database, so
>>>>> I
>>>>> will do that, ASAP. Thanks Neale.
>>>>>
>>>>> TomEE committers already admit that TomEE is not 'perfect'...yet, so I
>>>>> would assume these discussions are welcome. Honestly, I do my best to
>>>>> make
>>>>> sure I am on topic. I'm sure TomEE and OpenEJB is responsible for the
>>>>> @Stateless EJB transaction, triggered by @Schedule, and why is TomEE
>>>>> performing well with Derby when user click button, and managed beans
>>>>> call
>>>>> @Stateless EJB (DAO) to perform database operations... but why is
>>>>> TomEE
>>>>> not
>>>>> allowing my @Stateless EJB with @Schedule method() to perform
>>>>> well...with
>>>>> a
>>>>> large transaction.
>>>>>
>>>>> I have heard that geronimo has many many issues and does not have a
>>>>> good
>>>>> name/reputation, but regardless of the negative chatter I've seen on
>>>>> stackoverflow about geronimo, I still continue to use TomEE and I
>>>>> communicate my issues here on the list.
>>>>>
>>>>>
>>>>>
>>>>> On Thu, Dec 13, 2012 at 1:39 PM, Neale <ne...@metawerx.net> wrote:
>>>>>
>>>>> HyperSQL is another toy.
>>>>>>
>>>>>>
>>>>>> The specs below are great, Derby looks good in some cases, bad in
>>>>>> others.
>>>>>> But once again this is a very small test database.
>>>>>>
>>>>>> You might get 10% performance increase moving your database from
>>>>>> derby
>>>>>> to
>>>>>> mysql, or you might get a 10% performance loss. If you plan to use
>>>>>> it
>>>>>> commercially, use a real database because you will avoid all the
>>>>>> issues
>>>>>> when the database grows. All our (non-student) databases here are
>>>>>> 300mb-12gb. That is a very big difference to 17mb, but it depends on
>>>>>> what
>>>>>> data they store and how long they keep it. 17mb is just "playing".
>>>>>> So
>>>>>> 10%
>>>>>> performance difference up or down is not much fun to look at.
>>>>>>
>>>>>> Anyway - I don't think this is relevant to the TomEE list, and all
>>>>>> the
>>>>>> users/developers receiving these emails 10-20 times per day are
>>>>>> probably
>>>>>> not interested at all. It's very important to keep the discussion
>>>>>> relevant
>>>>>> so that people don't leave the TomEE list. The list gains more
>>>>>> members
>>>>>> from people seeing relevant information and staying subscribed, so we
>>>>>> shouldn't really discuss this here as it's off-topic.
>>>>>>
>>>>>> You are saying your real problem is JPA, so please try on another
>>>>>> database, and cut the problem into smaller pieces. Then you will
>>>>>> quickly
>>>>>> find out if it's a Derby issue, a JPA issue, or a TomEE issue.
>>>>>>
>>>>>> If TomEE is performing badly compared to Tomcat or JPA on a
>>>>>> command-line
>>>>>> JVM, then I'm sure the TomEE devs will jump on the issue and fix it
>>>>>> as
>>>>>> soon
>>>>>> as possible. Romain is quite amazing, if he sees a problem with
>>>>>> TomEE,
>>>>>> he
>>>>>> leaps on it! So let's try to limit the number of emails to be real
>>>>>> TomEE
>>>>>> issues so we don't waste his time ;-)
>>>>>>
>>>>>> Best Regards,
>>>>>> Neale
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
Re: DB access is very slow
Posted by Neale <ne...@metawerx.net>.
Actually I'd recommend removing the default HSQLDB reference in tomee.xml
I'm not sure if it's used for one of the examples or what it's used for, but
every time I"ve deployed a TomEE instance I've had to remove/disable it
manually because it overrides my real database definition
(META-INF/context.xml)
If it's used for something, maybe that should be documented somewhere? Or
otherwise maybe the release versions of TomEE can include it, but maybe have
it commented out?
Best Regards,
Neale
----- Original Message -----
From: "Romain Manni-Bucau" <rm...@gmail.com>
To: <us...@openejb.apache.org>
Sent: Friday, December 14, 2012 6:16 AM
Subject: Re: DB access is very slow
> hard to come back now ;)
>
> back on the topic,
>
> Well Howard think you should try to share with us some sample (not the
> full app please)
>
> i used a lot Geronimo transaction manager and i used ( a bit less)
> @Schedule and it worked fine
>
> i could understand OpenJPA begin slower on derby but geronimo not
> working is a different topic
>
> Side note: maybe your design is wrong, you manage a history in a
> @Schedule? not sure that's the best you can do
>
> Romain Manni-Bucau
> Twitter: @rmannibucau
> Blog: http://rmannibucau.wordpress.com/
> LinkedIn: http://fr.linkedin.com/in/rmannibucau
> Github: https://github.com/rmannibucau
>
>
>
> 2012/12/13 Neale <ne...@metawerx.net>:
>> Romain is great :-)
>>
>>
>> ----- Original Message ----- From: "Howard W. Smith, Jr."
>> <sm...@gmail.com>
>> To: <us...@openejb.apache.org>
>> Sent: Friday, December 14, 2012 6:09 AM
>>
>> Subject: Re: DB access is very slow
>>
>>
>>> Thank you very much Neale for all your responses. I have been open to
>>> searching around for a good java web host, but just didn't find it
>>> necessary...yet. At some point, I may be interested in your TomEE
>>> hosting
>>> service; when the project reaches a larger scope of endusers. Right now,
>>> I
>>> think we are doing okay with the hardware in place (and planning to have
>>> in
>>> place).
>>>
>>> I'll do my best to take any/all of your suggestions...especially about
>>> high
>>> volume. Romain is funny...he seems to welcome any/all discussion related
>>> to
>>> 'using TomEE'. :)
>>>
>>>
>>> On Thu, Dec 13, 2012 at 2:04 PM, Neale <ne...@metawerx.net> wrote:
>>>
>>>> Hi Howard,
>>>>
>>>> Your discussions are very interesting - I haven't unsubscribed from the
>>>> TomEE list yet even though there is such high volume. Lately I
>>>> actually
>>>> quite enjoy following your progress. There are a lot of emails - but
>>>> just
>>>> don't get too off-topic ;-) Try a few things on your own, then bring
>>>> your
>>>> findings to the list. Some questions are a bit off-topic so they're
>>>> better
>>>> being discussed on other lists.
>>>>
>>>> It's really exciting seeing you using TomEE for the first time and
>>>> running
>>>> into the initial problems. Those problems are very interesting. When
>>>> we
>>>> get to discussing Derby vs Hyper vs MySQL however, it's better to do
>>>> some
>>>> independant research and come back to the list afterwards. (IMHO)
>>>>
>>>> Anyway - I'd love to hear more about how your project turns out, and if
>>>> you want some free hosting on our new TomEE cluster, drop me a private
>>>> email and I'd be happy to give you some free space. Any experience we
>>>> have
>>>> with commerical TomEE customers is a great experience for us that we
>>>> can
>>>> blog about or share with the TomEE devs.
>>>>
>>>> Best Regards,
>>>> Neale
>>>>
>>>>
>>>>
>>>> ----- Original Message ----- From: "Howard W. Smith, Jr." <
>>>> smithh032772@gmail.com>
>>>> To: <us...@openejb.apache.org>
>>>> Sent: Friday, December 14, 2012 5:50 AM
>>>>
>>>> Subject: Re: DB access is very slow
>>>>
>>>>
>>>> Agreed about Romain, he is very amazing. Noted about HyperSQL, will
>>>> avoid
>>>>>
>>>>> that, and understood about 17mb = "playing". This is a new app that
>>>>> I've
>>>>> developed and it's being used every day for 'business', so definitely
>>>>> not
>>>>> playing, but I do want to move to prime-time and a faster database, so
>>>>> I
>>>>> will do that, ASAP. Thanks Neale.
>>>>>
>>>>> TomEE committers already admit that TomEE is not 'perfect'...yet, so I
>>>>> would assume these discussions are welcome. Honestly, I do my best to
>>>>> make
>>>>> sure I am on topic. I'm sure TomEE and OpenEJB is responsible for the
>>>>> @Stateless EJB transaction, triggered by @Schedule, and why is TomEE
>>>>> performing well with Derby when user click button, and managed beans
>>>>> call
>>>>> @Stateless EJB (DAO) to perform database operations... but why is
>>>>> TomEE
>>>>> not
>>>>> allowing my @Stateless EJB with @Schedule method() to perform
>>>>> well...with
>>>>> a
>>>>> large transaction.
>>>>>
>>>>> I have heard that geronimo has many many issues and does not have a
>>>>> good
>>>>> name/reputation, but regardless of the negative chatter I've seen on
>>>>> stackoverflow about geronimo, I still continue to use TomEE and I
>>>>> communicate my issues here on the list.
>>>>>
>>>>>
>>>>>
>>>>> On Thu, Dec 13, 2012 at 1:39 PM, Neale <ne...@metawerx.net> wrote:
>>>>>
>>>>> HyperSQL is another toy.
>>>>>>
>>>>>>
>>>>>> The specs below are great, Derby looks good in some cases, bad in
>>>>>> others.
>>>>>> But once again this is a very small test database.
>>>>>>
>>>>>> You might get 10% performance increase moving your database from
>>>>>> derby
>>>>>> to
>>>>>> mysql, or you might get a 10% performance loss. If you plan to use
>>>>>> it
>>>>>> commercially, use a real database because you will avoid all the
>>>>>> issues
>>>>>> when the database grows. All our (non-student) databases here are
>>>>>> 300mb-12gb. That is a very big difference to 17mb, but it depends on
>>>>>> what
>>>>>> data they store and how long they keep it. 17mb is just "playing".
>>>>>> So
>>>>>> 10%
>>>>>> performance difference up or down is not much fun to look at.
>>>>>>
>>>>>> Anyway - I don't think this is relevant to the TomEE list, and all
>>>>>> the
>>>>>> users/developers receiving these emails 10-20 times per day are
>>>>>> probably
>>>>>> not interested at all. It's very important to keep the discussion
>>>>>> relevant
>>>>>> so that people don't leave the TomEE list. The list gains more
>>>>>> members
>>>>>> from people seeing relevant information and staying subscribed, so we
>>>>>> shouldn't really discuss this here as it's off-topic.
>>>>>>
>>>>>> You are saying your real problem is JPA, so please try on another
>>>>>> database, and cut the problem into smaller pieces. Then you will
>>>>>> quickly
>>>>>> find out if it's a Derby issue, a JPA issue, or a TomEE issue.
>>>>>>
>>>>>> If TomEE is performing badly compared to Tomcat or JPA on a
>>>>>> command-line
>>>>>> JVM, then I'm sure the TomEE devs will jump on the issue and fix it
>>>>>> as
>>>>>> soon
>>>>>> as possible. Romain is quite amazing, if he sees a problem with
>>>>>> TomEE,
>>>>>> he
>>>>>> leaps on it! So let's try to limit the number of emails to be real
>>>>>> TomEE
>>>>>> issues so we don't waste his time ;-)
>>>>>>
>>>>>> Best Regards,
>>>>>> Neale
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
Re: DB access is very slow
Posted by Romain Manni-Bucau <rm...@gmail.com>.
hard to come back now ;)
back on the topic,
Well Howard think you should try to share with us some sample (not the
full app please)
i used a lot Geronimo transaction manager and i used ( a bit less)
@Schedule and it worked fine
i could understand OpenJPA begin slower on derby but geronimo not
working is a different topic
Side note: maybe your design is wrong, you manage a history in a
@Schedule? not sure that's the best you can do
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau
2012/12/13 Neale <ne...@metawerx.net>:
> Romain is great :-)
>
>
> ----- Original Message ----- From: "Howard W. Smith, Jr."
> <sm...@gmail.com>
> To: <us...@openejb.apache.org>
> Sent: Friday, December 14, 2012 6:09 AM
>
> Subject: Re: DB access is very slow
>
>
>> Thank you very much Neale for all your responses. I have been open to
>> searching around for a good java web host, but just didn't find it
>> necessary...yet. At some point, I may be interested in your TomEE hosting
>> service; when the project reaches a larger scope of endusers. Right now, I
>> think we are doing okay with the hardware in place (and planning to have
>> in
>> place).
>>
>> I'll do my best to take any/all of your suggestions...especially about
>> high
>> volume. Romain is funny...he seems to welcome any/all discussion related
>> to
>> 'using TomEE'. :)
>>
>>
>> On Thu, Dec 13, 2012 at 2:04 PM, Neale <ne...@metawerx.net> wrote:
>>
>>> Hi Howard,
>>>
>>> Your discussions are very interesting - I haven't unsubscribed from the
>>> TomEE list yet even though there is such high volume. Lately I actually
>>> quite enjoy following your progress. There are a lot of emails - but
>>> just
>>> don't get too off-topic ;-) Try a few things on your own, then bring
>>> your
>>> findings to the list. Some questions are a bit off-topic so they're
>>> better
>>> being discussed on other lists.
>>>
>>> It's really exciting seeing you using TomEE for the first time and
>>> running
>>> into the initial problems. Those problems are very interesting. When we
>>> get to discussing Derby vs Hyper vs MySQL however, it's better to do some
>>> independant research and come back to the list afterwards. (IMHO)
>>>
>>> Anyway - I'd love to hear more about how your project turns out, and if
>>> you want some free hosting on our new TomEE cluster, drop me a private
>>> email and I'd be happy to give you some free space. Any experience we
>>> have
>>> with commerical TomEE customers is a great experience for us that we can
>>> blog about or share with the TomEE devs.
>>>
>>> Best Regards,
>>> Neale
>>>
>>>
>>>
>>> ----- Original Message ----- From: "Howard W. Smith, Jr." <
>>> smithh032772@gmail.com>
>>> To: <us...@openejb.apache.org>
>>> Sent: Friday, December 14, 2012 5:50 AM
>>>
>>> Subject: Re: DB access is very slow
>>>
>>>
>>> Agreed about Romain, he is very amazing. Noted about HyperSQL, will
>>> avoid
>>>>
>>>> that, and understood about 17mb = "playing". This is a new app that I've
>>>> developed and it's being used every day for 'business', so definitely
>>>> not
>>>> playing, but I do want to move to prime-time and a faster database, so I
>>>> will do that, ASAP. Thanks Neale.
>>>>
>>>> TomEE committers already admit that TomEE is not 'perfect'...yet, so I
>>>> would assume these discussions are welcome. Honestly, I do my best to
>>>> make
>>>> sure I am on topic. I'm sure TomEE and OpenEJB is responsible for the
>>>> @Stateless EJB transaction, triggered by @Schedule, and why is TomEE
>>>> performing well with Derby when user click button, and managed beans
>>>> call
>>>> @Stateless EJB (DAO) to perform database operations... but why is TomEE
>>>> not
>>>> allowing my @Stateless EJB with @Schedule method() to perform
>>>> well...with
>>>> a
>>>> large transaction.
>>>>
>>>> I have heard that geronimo has many many issues and does not have a good
>>>> name/reputation, but regardless of the negative chatter I've seen on
>>>> stackoverflow about geronimo, I still continue to use TomEE and I
>>>> communicate my issues here on the list.
>>>>
>>>>
>>>>
>>>> On Thu, Dec 13, 2012 at 1:39 PM, Neale <ne...@metawerx.net> wrote:
>>>>
>>>> HyperSQL is another toy.
>>>>>
>>>>>
>>>>> The specs below are great, Derby looks good in some cases, bad in
>>>>> others.
>>>>> But once again this is a very small test database.
>>>>>
>>>>> You might get 10% performance increase moving your database from derby
>>>>> to
>>>>> mysql, or you might get a 10% performance loss. If you plan to use it
>>>>> commercially, use a real database because you will avoid all the issues
>>>>> when the database grows. All our (non-student) databases here are
>>>>> 300mb-12gb. That is a very big difference to 17mb, but it depends on
>>>>> what
>>>>> data they store and how long they keep it. 17mb is just "playing". So
>>>>> 10%
>>>>> performance difference up or down is not much fun to look at.
>>>>>
>>>>> Anyway - I don't think this is relevant to the TomEE list, and all the
>>>>> users/developers receiving these emails 10-20 times per day are
>>>>> probably
>>>>> not interested at all. It's very important to keep the discussion
>>>>> relevant
>>>>> so that people don't leave the TomEE list. The list gains more
>>>>> members
>>>>> from people seeing relevant information and staying subscribed, so we
>>>>> shouldn't really discuss this here as it's off-topic.
>>>>>
>>>>> You are saying your real problem is JPA, so please try on another
>>>>> database, and cut the problem into smaller pieces. Then you will
>>>>> quickly
>>>>> find out if it's a Derby issue, a JPA issue, or a TomEE issue.
>>>>>
>>>>> If TomEE is performing badly compared to Tomcat or JPA on a
>>>>> command-line
>>>>> JVM, then I'm sure the TomEE devs will jump on the issue and fix it as
>>>>> soon
>>>>> as possible. Romain is quite amazing, if he sees a problem with TomEE,
>>>>> he
>>>>> leaps on it! So let's try to limit the number of emails to be real
>>>>> TomEE
>>>>> issues so we don't waste his time ;-)
>>>>>
>>>>> Best Regards,
>>>>> Neale
>>>>>
>>>>>
>>>>
>>>
>>
>
Re: DB access is very slow
Posted by Neale <ne...@metawerx.net>.
Romain is great :-)
----- Original Message -----
From: "Howard W. Smith, Jr." <sm...@gmail.com>
To: <us...@openejb.apache.org>
Sent: Friday, December 14, 2012 6:09 AM
Subject: Re: DB access is very slow
> Thank you very much Neale for all your responses. I have been open to
> searching around for a good java web host, but just didn't find it
> necessary...yet. At some point, I may be interested in your TomEE hosting
> service; when the project reaches a larger scope of endusers. Right now, I
> think we are doing okay with the hardware in place (and planning to have
> in
> place).
>
> I'll do my best to take any/all of your suggestions...especially about
> high
> volume. Romain is funny...he seems to welcome any/all discussion related
> to
> 'using TomEE'. :)
>
>
> On Thu, Dec 13, 2012 at 2:04 PM, Neale <ne...@metawerx.net> wrote:
>
>> Hi Howard,
>>
>> Your discussions are very interesting - I haven't unsubscribed from the
>> TomEE list yet even though there is such high volume. Lately I actually
>> quite enjoy following your progress. There are a lot of emails - but
>> just
>> don't get too off-topic ;-) Try a few things on your own, then bring
>> your
>> findings to the list. Some questions are a bit off-topic so they're
>> better
>> being discussed on other lists.
>>
>> It's really exciting seeing you using TomEE for the first time and
>> running
>> into the initial problems. Those problems are very interesting. When we
>> get to discussing Derby vs Hyper vs MySQL however, it's better to do some
>> independant research and come back to the list afterwards. (IMHO)
>>
>> Anyway - I'd love to hear more about how your project turns out, and if
>> you want some free hosting on our new TomEE cluster, drop me a private
>> email and I'd be happy to give you some free space. Any experience we
>> have
>> with commerical TomEE customers is a great experience for us that we can
>> blog about or share with the TomEE devs.
>>
>> Best Regards,
>> Neale
>>
>>
>>
>> ----- Original Message ----- From: "Howard W. Smith, Jr." <
>> smithh032772@gmail.com>
>> To: <us...@openejb.apache.org>
>> Sent: Friday, December 14, 2012 5:50 AM
>>
>> Subject: Re: DB access is very slow
>>
>>
>> Agreed about Romain, he is very amazing. Noted about HyperSQL, will
>> avoid
>>> that, and understood about 17mb = "playing". This is a new app that I've
>>> developed and it's being used every day for 'business', so definitely
>>> not
>>> playing, but I do want to move to prime-time and a faster database, so I
>>> will do that, ASAP. Thanks Neale.
>>>
>>> TomEE committers already admit that TomEE is not 'perfect'...yet, so I
>>> would assume these discussions are welcome. Honestly, I do my best to
>>> make
>>> sure I am on topic. I'm sure TomEE and OpenEJB is responsible for the
>>> @Stateless EJB transaction, triggered by @Schedule, and why is TomEE
>>> performing well with Derby when user click button, and managed beans
>>> call
>>> @Stateless EJB (DAO) to perform database operations... but why is TomEE
>>> not
>>> allowing my @Stateless EJB with @Schedule method() to perform
>>> well...with
>>> a
>>> large transaction.
>>>
>>> I have heard that geronimo has many many issues and does not have a good
>>> name/reputation, but regardless of the negative chatter I've seen on
>>> stackoverflow about geronimo, I still continue to use TomEE and I
>>> communicate my issues here on the list.
>>>
>>>
>>>
>>> On Thu, Dec 13, 2012 at 1:39 PM, Neale <ne...@metawerx.net> wrote:
>>>
>>> HyperSQL is another toy.
>>>>
>>>> The specs below are great, Derby looks good in some cases, bad in
>>>> others.
>>>> But once again this is a very small test database.
>>>>
>>>> You might get 10% performance increase moving your database from derby
>>>> to
>>>> mysql, or you might get a 10% performance loss. If you plan to use it
>>>> commercially, use a real database because you will avoid all the issues
>>>> when the database grows. All our (non-student) databases here are
>>>> 300mb-12gb. That is a very big difference to 17mb, but it depends on
>>>> what
>>>> data they store and how long they keep it. 17mb is just "playing". So
>>>> 10%
>>>> performance difference up or down is not much fun to look at.
>>>>
>>>> Anyway - I don't think this is relevant to the TomEE list, and all the
>>>> users/developers receiving these emails 10-20 times per day are
>>>> probably
>>>> not interested at all. It's very important to keep the discussion
>>>> relevant
>>>> so that people don't leave the TomEE list. The list gains more
>>>> members
>>>> from people seeing relevant information and staying subscribed, so we
>>>> shouldn't really discuss this here as it's off-topic.
>>>>
>>>> You are saying your real problem is JPA, so please try on another
>>>> database, and cut the problem into smaller pieces. Then you will
>>>> quickly
>>>> find out if it's a Derby issue, a JPA issue, or a TomEE issue.
>>>>
>>>> If TomEE is performing badly compared to Tomcat or JPA on a
>>>> command-line
>>>> JVM, then I'm sure the TomEE devs will jump on the issue and fix it as
>>>> soon
>>>> as possible. Romain is quite amazing, if he sees a problem with TomEE,
>>>> he
>>>> leaps on it! So let's try to limit the number of emails to be real
>>>> TomEE
>>>> issues so we don't waste his time ;-)
>>>>
>>>> Best Regards,
>>>> Neale
>>>>
>>>>
>>>
>>
>
Re: DB access is very slow
Posted by Neale <ne...@metawerx.net>.
Definitely ask him about all the @stuff.
That's his area!
----- Original Message -----
From: "Howard W. Smith, Jr." <sm...@gmail.com>
To: <us...@openejb.apache.org>
Sent: Friday, December 14, 2012 6:09 AM
Subject: Re: DB access is very slow
> Thank you very much Neale for all your responses. I have been open to
> searching around for a good java web host, but just didn't find it
> necessary...yet. At some point, I may be interested in your TomEE hosting
> service; when the project reaches a larger scope of endusers. Right now, I
> think we are doing okay with the hardware in place (and planning to have
> in
> place).
>
> I'll do my best to take any/all of your suggestions...especially about
> high
> volume. Romain is funny...he seems to welcome any/all discussion related
> to
> 'using TomEE'. :)
>
>
> On Thu, Dec 13, 2012 at 2:04 PM, Neale <ne...@metawerx.net> wrote:
>
>> Hi Howard,
>>
>> Your discussions are very interesting - I haven't unsubscribed from the
>> TomEE list yet even though there is such high volume. Lately I actually
>> quite enjoy following your progress. There are a lot of emails - but
>> just
>> don't get too off-topic ;-) Try a few things on your own, then bring
>> your
>> findings to the list. Some questions are a bit off-topic so they're
>> better
>> being discussed on other lists.
>>
>> It's really exciting seeing you using TomEE for the first time and
>> running
>> into the initial problems. Those problems are very interesting. When we
>> get to discussing Derby vs Hyper vs MySQL however, it's better to do some
>> independant research and come back to the list afterwards. (IMHO)
>>
>> Anyway - I'd love to hear more about how your project turns out, and if
>> you want some free hosting on our new TomEE cluster, drop me a private
>> email and I'd be happy to give you some free space. Any experience we
>> have
>> with commerical TomEE customers is a great experience for us that we can
>> blog about or share with the TomEE devs.
>>
>> Best Regards,
>> Neale
>>
>>
>>
>> ----- Original Message ----- From: "Howard W. Smith, Jr." <
>> smithh032772@gmail.com>
>> To: <us...@openejb.apache.org>
>> Sent: Friday, December 14, 2012 5:50 AM
>>
>> Subject: Re: DB access is very slow
>>
>>
>> Agreed about Romain, he is very amazing. Noted about HyperSQL, will
>> avoid
>>> that, and understood about 17mb = "playing". This is a new app that I've
>>> developed and it's being used every day for 'business', so definitely
>>> not
>>> playing, but I do want to move to prime-time and a faster database, so I
>>> will do that, ASAP. Thanks Neale.
>>>
>>> TomEE committers already admit that TomEE is not 'perfect'...yet, so I
>>> would assume these discussions are welcome. Honestly, I do my best to
>>> make
>>> sure I am on topic. I'm sure TomEE and OpenEJB is responsible for the
>>> @Stateless EJB transaction, triggered by @Schedule, and why is TomEE
>>> performing well with Derby when user click button, and managed beans
>>> call
>>> @Stateless EJB (DAO) to perform database operations... but why is TomEE
>>> not
>>> allowing my @Stateless EJB with @Schedule method() to perform
>>> well...with
>>> a
>>> large transaction.
>>>
>>> I have heard that geronimo has many many issues and does not have a good
>>> name/reputation, but regardless of the negative chatter I've seen on
>>> stackoverflow about geronimo, I still continue to use TomEE and I
>>> communicate my issues here on the list.
>>>
>>>
>>>
>>> On Thu, Dec 13, 2012 at 1:39 PM, Neale <ne...@metawerx.net> wrote:
>>>
>>> HyperSQL is another toy.
>>>>
>>>> The specs below are great, Derby looks good in some cases, bad in
>>>> others.
>>>> But once again this is a very small test database.
>>>>
>>>> You might get 10% performance increase moving your database from derby
>>>> to
>>>> mysql, or you might get a 10% performance loss. If you plan to use it
>>>> commercially, use a real database because you will avoid all the issues
>>>> when the database grows. All our (non-student) databases here are
>>>> 300mb-12gb. That is a very big difference to 17mb, but it depends on
>>>> what
>>>> data they store and how long they keep it. 17mb is just "playing". So
>>>> 10%
>>>> performance difference up or down is not much fun to look at.
>>>>
>>>> Anyway - I don't think this is relevant to the TomEE list, and all the
>>>> users/developers receiving these emails 10-20 times per day are
>>>> probably
>>>> not interested at all. It's very important to keep the discussion
>>>> relevant
>>>> so that people don't leave the TomEE list. The list gains more
>>>> members
>>>> from people seeing relevant information and staying subscribed, so we
>>>> shouldn't really discuss this here as it's off-topic.
>>>>
>>>> You are saying your real problem is JPA, so please try on another
>>>> database, and cut the problem into smaller pieces. Then you will
>>>> quickly
>>>> find out if it's a Derby issue, a JPA issue, or a TomEE issue.
>>>>
>>>> If TomEE is performing badly compared to Tomcat or JPA on a
>>>> command-line
>>>> JVM, then I'm sure the TomEE devs will jump on the issue and fix it as
>>>> soon
>>>> as possible. Romain is quite amazing, if he sees a problem with TomEE,
>>>> he
>>>> leaps on it! So let's try to limit the number of emails to be real
>>>> TomEE
>>>> issues so we don't waste his time ;-)
>>>>
>>>> Best Regards,
>>>> Neale
>>>>
>>>>
>>>
>>
>
Re: DB access is very slow
Posted by "Howard W. Smith, Jr." <sm...@gmail.com>.
Thank you very much Neale for all your responses. I have been open to
searching around for a good java web host, but just didn't find it
necessary...yet. At some point, I may be interested in your TomEE hosting
service; when the project reaches a larger scope of endusers. Right now, I
think we are doing okay with the hardware in place (and planning to have in
place).
I'll do my best to take any/all of your suggestions...especially about high
volume. Romain is funny...he seems to welcome any/all discussion related to
'using TomEE'. :)
On Thu, Dec 13, 2012 at 2:04 PM, Neale <ne...@metawerx.net> wrote:
> Hi Howard,
>
> Your discussions are very interesting - I haven't unsubscribed from the
> TomEE list yet even though there is such high volume. Lately I actually
> quite enjoy following your progress. There are a lot of emails - but just
> don't get too off-topic ;-) Try a few things on your own, then bring your
> findings to the list. Some questions are a bit off-topic so they're better
> being discussed on other lists.
>
> It's really exciting seeing you using TomEE for the first time and running
> into the initial problems. Those problems are very interesting. When we
> get to discussing Derby vs Hyper vs MySQL however, it's better to do some
> independant research and come back to the list afterwards. (IMHO)
>
> Anyway - I'd love to hear more about how your project turns out, and if
> you want some free hosting on our new TomEE cluster, drop me a private
> email and I'd be happy to give you some free space. Any experience we have
> with commerical TomEE customers is a great experience for us that we can
> blog about or share with the TomEE devs.
>
> Best Regards,
> Neale
>
>
>
> ----- Original Message ----- From: "Howard W. Smith, Jr." <
> smithh032772@gmail.com>
> To: <us...@openejb.apache.org>
> Sent: Friday, December 14, 2012 5:50 AM
>
> Subject: Re: DB access is very slow
>
>
> Agreed about Romain, he is very amazing. Noted about HyperSQL, will avoid
>> that, and understood about 17mb = "playing". This is a new app that I've
>> developed and it's being used every day for 'business', so definitely not
>> playing, but I do want to move to prime-time and a faster database, so I
>> will do that, ASAP. Thanks Neale.
>>
>> TomEE committers already admit that TomEE is not 'perfect'...yet, so I
>> would assume these discussions are welcome. Honestly, I do my best to make
>> sure I am on topic. I'm sure TomEE and OpenEJB is responsible for the
>> @Stateless EJB transaction, triggered by @Schedule, and why is TomEE
>> performing well with Derby when user click button, and managed beans call
>> @Stateless EJB (DAO) to perform database operations... but why is TomEE
>> not
>> allowing my @Stateless EJB with @Schedule method() to perform well...with
>> a
>> large transaction.
>>
>> I have heard that geronimo has many many issues and does not have a good
>> name/reputation, but regardless of the negative chatter I've seen on
>> stackoverflow about geronimo, I still continue to use TomEE and I
>> communicate my issues here on the list.
>>
>>
>>
>> On Thu, Dec 13, 2012 at 1:39 PM, Neale <ne...@metawerx.net> wrote:
>>
>> HyperSQL is another toy.
>>>
>>> The specs below are great, Derby looks good in some cases, bad in others.
>>> But once again this is a very small test database.
>>>
>>> You might get 10% performance increase moving your database from derby to
>>> mysql, or you might get a 10% performance loss. If you plan to use it
>>> commercially, use a real database because you will avoid all the issues
>>> when the database grows. All our (non-student) databases here are
>>> 300mb-12gb. That is a very big difference to 17mb, but it depends on what
>>> data they store and how long they keep it. 17mb is just "playing". So
>>> 10%
>>> performance difference up or down is not much fun to look at.
>>>
>>> Anyway - I don't think this is relevant to the TomEE list, and all the
>>> users/developers receiving these emails 10-20 times per day are probably
>>> not interested at all. It's very important to keep the discussion
>>> relevant
>>> so that people don't leave the TomEE list. The list gains more members
>>> from people seeing relevant information and staying subscribed, so we
>>> shouldn't really discuss this here as it's off-topic.
>>>
>>> You are saying your real problem is JPA, so please try on another
>>> database, and cut the problem into smaller pieces. Then you will quickly
>>> find out if it's a Derby issue, a JPA issue, or a TomEE issue.
>>>
>>> If TomEE is performing badly compared to Tomcat or JPA on a command-line
>>> JVM, then I'm sure the TomEE devs will jump on the issue and fix it as
>>> soon
>>> as possible. Romain is quite amazing, if he sees a problem with TomEE,
>>> he
>>> leaps on it! So let's try to limit the number of emails to be real
>>> TomEE
>>> issues so we don't waste his time ;-)
>>>
>>> Best Regards,
>>> Neale
>>>
>>>
>>
>
Re: DB access is very slow
Posted by Neale <ne...@metawerx.net>.
Hi Howard,
Your discussions are very interesting - I haven't unsubscribed from the
TomEE list yet even though there is such high volume. Lately I actually
quite enjoy following your progress. There are a lot of emails - but just
don't get too off-topic ;-) Try a few things on your own, then bring your
findings to the list. Some questions are a bit off-topic so they're better
being discussed on other lists.
It's really exciting seeing you using TomEE for the first time and running
into the initial problems. Those problems are very interesting. When we
get to discussing Derby vs Hyper vs MySQL however, it's better to do some
independant research and come back to the list afterwards. (IMHO)
Anyway - I'd love to hear more about how your project turns out, and if you
want some free hosting on our new TomEE cluster, drop me a private email and
I'd be happy to give you some free space. Any experience we have with
commerical TomEE customers is a great experience for us that we can blog
about or share with the TomEE devs.
Best Regards,
Neale
----- Original Message -----
From: "Howard W. Smith, Jr." <sm...@gmail.com>
To: <us...@openejb.apache.org>
Sent: Friday, December 14, 2012 5:50 AM
Subject: Re: DB access is very slow
> Agreed about Romain, he is very amazing. Noted about HyperSQL, will avoid
> that, and understood about 17mb = "playing". This is a new app that I've
> developed and it's being used every day for 'business', so definitely not
> playing, but I do want to move to prime-time and a faster database, so I
> will do that, ASAP. Thanks Neale.
>
> TomEE committers already admit that TomEE is not 'perfect'...yet, so I
> would assume these discussions are welcome. Honestly, I do my best to make
> sure I am on topic. I'm sure TomEE and OpenEJB is responsible for the
> @Stateless EJB transaction, triggered by @Schedule, and why is TomEE
> performing well with Derby when user click button, and managed beans call
> @Stateless EJB (DAO) to perform database operations... but why is TomEE
> not
> allowing my @Stateless EJB with @Schedule method() to perform well...with
> a
> large transaction.
>
> I have heard that geronimo has many many issues and does not have a good
> name/reputation, but regardless of the negative chatter I've seen on
> stackoverflow about geronimo, I still continue to use TomEE and I
> communicate my issues here on the list.
>
>
>
> On Thu, Dec 13, 2012 at 1:39 PM, Neale <ne...@metawerx.net> wrote:
>
>> HyperSQL is another toy.
>>
>> The specs below are great, Derby looks good in some cases, bad in others.
>> But once again this is a very small test database.
>>
>> You might get 10% performance increase moving your database from derby to
>> mysql, or you might get a 10% performance loss. If you plan to use it
>> commercially, use a real database because you will avoid all the issues
>> when the database grows. All our (non-student) databases here are
>> 300mb-12gb. That is a very big difference to 17mb, but it depends on what
>> data they store and how long they keep it. 17mb is just "playing". So
>> 10%
>> performance difference up or down is not much fun to look at.
>>
>> Anyway - I don't think this is relevant to the TomEE list, and all the
>> users/developers receiving these emails 10-20 times per day are probably
>> not interested at all. It's very important to keep the discussion
>> relevant
>> so that people don't leave the TomEE list. The list gains more members
>> from people seeing relevant information and staying subscribed, so we
>> shouldn't really discuss this here as it's off-topic.
>>
>> You are saying your real problem is JPA, so please try on another
>> database, and cut the problem into smaller pieces. Then you will quickly
>> find out if it's a Derby issue, a JPA issue, or a TomEE issue.
>>
>> If TomEE is performing badly compared to Tomcat or JPA on a command-line
>> JVM, then I'm sure the TomEE devs will jump on the issue and fix it as
>> soon
>> as possible. Romain is quite amazing, if he sees a problem with TomEE,
>> he
>> leaps on it! So let's try to limit the number of emails to be real
>> TomEE
>> issues so we don't waste his time ;-)
>>
>> Best Regards,
>> Neale
>>
>
Re: DB access is very slow
Posted by "Howard W. Smith, Jr." <sm...@gmail.com>.
Smiling...forgot to mention... the database would have been much larger (if
I kept all the 'historic' / obsolete data from 1998, but decided to keep
only 3 years worth of data, and archive the rest in the old dBase IV
database files) )... the first version of my app, dBase IV app, created in
1994/1995, and recently migrated from dBAse IV to Java Server Faces web
application, and the endusers (my family) are loving the new web
application, the scalability, the accessibility, the HTML5 web application
features (can be used on mobile devices... iPad, Android, phones, tablets,
etc...) and yes, the speed too. This is the first time I actually had a
speed/performance issue, and I'm glad TomEE/openejb list is trying to help
rectify the issue.
Would I have this performance issue if I stuck it out with Glassfish? Good
question and that answer remains to be seen. I've decided to stick with
TomEE and not really use Glassfish as the 'reference implementation'. Going
forward, I'll use TomEE as the reference implementation. :)
On Thu, Dec 13, 2012 at 1:50 PM, Howard W. Smith, Jr. <
smithh032772@gmail.com> wrote:
> Agreed about Romain, he is very amazing. Noted about HyperSQL, will avoid
> that, and understood about 17mb = "playing". This is a new app that I've
> developed and it's being used every day for 'business', so definitely not
> playing, but I do want to move to prime-time and a faster database, so I
> will do that, ASAP. Thanks Neale.
>
> TomEE committers already admit that TomEE is not 'perfect'...yet, so I
> would assume these discussions are welcome. Honestly, I do my best to make
> sure I am on topic. I'm sure TomEE and OpenEJB is responsible for the
> @Stateless EJB transaction, triggered by @Schedule, and why is TomEE
> performing well with Derby when user click button, and managed beans call
> @Stateless EJB (DAO) to perform database operations... but why is TomEE not
> allowing my @Stateless EJB with @Schedule method() to perform well...with a
> large transaction.
>
> I have heard that geronimo has many many issues and does not have a good
> name/reputation, but regardless of the negative chatter I've seen on
> stackoverflow about geronimo, I still continue to use TomEE and I
> communicate my issues here on the list.
>
>
>
> On Thu, Dec 13, 2012 at 1:39 PM, Neale <ne...@metawerx.net> wrote:
>
>> HyperSQL is another toy.
>>
>> The specs below are great, Derby looks good in some cases, bad in others.
>> But once again this is a very small test database.
>>
>> You might get 10% performance increase moving your database from derby to
>> mysql, or you might get a 10% performance loss. If you plan to use it
>> commercially, use a real database because you will avoid all the issues
>> when the database grows. All our (non-student) databases here are
>> 300mb-12gb. That is a very big difference to 17mb, but it depends on what
>> data they store and how long they keep it. 17mb is just "playing". So 10%
>> performance difference up or down is not much fun to look at.
>>
>> Anyway - I don't think this is relevant to the TomEE list, and all the
>> users/developers receiving these emails 10-20 times per day are probably
>> not interested at all. It's very important to keep the discussion relevant
>> so that people don't leave the TomEE list. The list gains more members
>> from people seeing relevant information and staying subscribed, so we
>> shouldn't really discuss this here as it's off-topic.
>>
>> You are saying your real problem is JPA, so please try on another
>> database, and cut the problem into smaller pieces. Then you will quickly
>> find out if it's a Derby issue, a JPA issue, or a TomEE issue.
>>
>> If TomEE is performing badly compared to Tomcat or JPA on a command-line
>> JVM, then I'm sure the TomEE devs will jump on the issue and fix it as soon
>> as possible. Romain is quite amazing, if he sees a problem with TomEE, he
>> leaps on it! So let's try to limit the number of emails to be real TomEE
>> issues so we don't waste his time ;-)
>>
>> Best Regards,
>> Neale
>>
>
>
Re: DB access is very slow
Posted by "Howard W. Smith, Jr." <sm...@gmail.com>.
Agreed about Romain, he is very amazing. Noted about HyperSQL, will avoid
that, and understood about 17mb = "playing". This is a new app that I've
developed and it's being used every day for 'business', so definitely not
playing, but I do want to move to prime-time and a faster database, so I
will do that, ASAP. Thanks Neale.
TomEE committers already admit that TomEE is not 'perfect'...yet, so I
would assume these discussions are welcome. Honestly, I do my best to make
sure I am on topic. I'm sure TomEE and OpenEJB is responsible for the
@Stateless EJB transaction, triggered by @Schedule, and why is TomEE
performing well with Derby when user click button, and managed beans call
@Stateless EJB (DAO) to perform database operations... but why is TomEE not
allowing my @Stateless EJB with @Schedule method() to perform well...with a
large transaction.
I have heard that geronimo has many many issues and does not have a good
name/reputation, but regardless of the negative chatter I've seen on
stackoverflow about geronimo, I still continue to use TomEE and I
communicate my issues here on the list.
On Thu, Dec 13, 2012 at 1:39 PM, Neale <ne...@metawerx.net> wrote:
> HyperSQL is another toy.
>
> The specs below are great, Derby looks good in some cases, bad in others.
> But once again this is a very small test database.
>
> You might get 10% performance increase moving your database from derby to
> mysql, or you might get a 10% performance loss. If you plan to use it
> commercially, use a real database because you will avoid all the issues
> when the database grows. All our (non-student) databases here are
> 300mb-12gb. That is a very big difference to 17mb, but it depends on what
> data they store and how long they keep it. 17mb is just "playing". So 10%
> performance difference up or down is not much fun to look at.
>
> Anyway - I don't think this is relevant to the TomEE list, and all the
> users/developers receiving these emails 10-20 times per day are probably
> not interested at all. It's very important to keep the discussion relevant
> so that people don't leave the TomEE list. The list gains more members
> from people seeing relevant information and staying subscribed, so we
> shouldn't really discuss this here as it's off-topic.
>
> You are saying your real problem is JPA, so please try on another
> database, and cut the problem into smaller pieces. Then you will quickly
> find out if it's a Derby issue, a JPA issue, or a TomEE issue.
>
> If TomEE is performing badly compared to Tomcat or JPA on a command-line
> JVM, then I'm sure the TomEE devs will jump on the issue and fix it as soon
> as possible. Romain is quite amazing, if he sees a problem with TomEE, he
> leaps on it! So let's try to limit the number of emails to be real TomEE
> issues so we don't waste his time ;-)
>
> Best Regards,
> Neale
>
Re: DB access is very slow
Posted by Neale <ne...@metawerx.net>.
HyperSQL is another toy.
The specs below are great, Derby looks good in some cases, bad in others.
But once again this is a very small test database.
You might get 10% performance increase moving your database from derby to
mysql, or you might get a 10% performance loss. If you plan to use it
commercially, use a real database because you will avoid all the issues when
the database grows. All our (non-student) databases here are 300mb-12gb.
That is a very big difference to 17mb, but it depends on what data they
store and how long they keep it. 17mb is just "playing". So 10%
performance difference up or down is not much fun to look at.
Anyway - I don't think this is relevant to the TomEE list, and all the
users/developers receiving these emails 10-20 times per day are probably not
interested at all. It's very important to keep the discussion relevant so
that people don't leave the TomEE list. The list gains more members from
people seeing relevant information and staying subscribed, so we shouldn't
really discuss this here as it's off-topic.
You are saying your real problem is JPA, so please try on another database,
and cut the problem into smaller pieces. Then you will quickly find out if
it's a Derby issue, a JPA issue, or a TomEE issue.
If TomEE is performing badly compared to Tomcat or JPA on a command-line
JVM, then I'm sure the TomEE devs will jump on the issue and fix it as soon
as possible. Romain is quite amazing, if he sees a problem with TomEE, he
leaps on it! So let's try to limit the number of emails to be real TomEE
issues so we don't waste his time ;-)
Best Regards,
Neale
Re: DB access is very slow
Posted by "Howard W. Smith, Jr." <sm...@gmail.com>.
That's the benchmark website that I've been referring to, and that is what
I've been using to justify apache derby. I don't know how reliable this
website is though. :)
On Thu, Dec 13, 2012 at 1:13 PM, Romain Manni-Bucau
<rm...@gmail.com>wrote:
>
> yep, more or less same note can apply to windows i guess :p
>
> that's said, i'm not sure of the data but here some figures:
> http://www.jpab.org/EclipseLink/Derby/server/OpenJPA/Derby/server.html
>
> don't know why OpenJPA is so slow
>
> @Mark: any idea?
>
> FYI the same with MySQL:
> http://www.jpab.org/EclipseLink/MySQL/server/OpenJPA/MySQL/server.html
Re: DB access is very slow
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Hey,
yep, more or less same note can apply to windows i guess :p
that's said, i'm not sure of the data but here some figures:
http://www.jpab.org/EclipseLink/Derby/server/OpenJPA/Derby/server.html
don't know why OpenJPA is so slow
@Mark: any idea?
FYI the same with MySQL:
http://www.jpab.org/EclipseLink/MySQL/server/OpenJPA/MySQL/server.html
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau
2012/12/13 Neale <ne...@metawerx.net>:
> Hi Howard,
>
> Derby is an in-memory java-based DB, so with a 100mb database it performs
> great.
>
> Once you start putting real data into it, it fails horribly. It's designed
> for testing, and never for production (read the docs).
>
> Please never use it as a "production" database. We had a customer here
> using it, and after their database grew to 2gb in size it started consuming
> 100% CPU on multiple CPUs and displaying huge disk I/O and GC. They
> converted to MySQL and their usage has dropped to less than 1% of what derby
> was using.
>
> But it's a great DB for testing small apps, and with very small apps it may
> even perform faster than a real DB ;-)
>
> Anyway, with your specific problem, for now I would recommend separating the
> database and JPA so you can measure them both separately.
>
> It's always easier to solve a problem by breaking it into smaller pieces.
>
> Best Regards,
> Neale Rudd
> Metawerx Pty Ltd
> www.metawerx.net
>
>
> ----- Original Message ----- From: "Howard W. Smith, Jr."
> <sm...@gmail.com>
> To: <us...@openejb.apache.org>
> Sent: Friday, December 14, 2012 3:48 AM
>
> Subject: Re: DB access is very slow
>
>
>> 1. In a .zip file, the Derby database is at least 17MB
>>
>> 2. yes, have indexes, i did that months ago after reviewing the apache
>> derby tuning database PDF
>>
>> 3. trust me, it is lightning fast when the 'norm' code is performing
>> database operations, concurrently; 'norm' code/approach = managed beans
>> have @EJB, @EJB = DAO
>>
>> 4. the approach discussed in this email thread and other-related email
>> threads, I did an outside-of-the-norm approach for my app
>>
>> 5. outside-of-the-norm approach = @Stateless EJB with @Schedule method()
>> calls multiple @Stateless EJBs (DAO) to lookup as well as simple
>> insert/persist statements
>>
>> 6. lightning fast? the outside-of-the-norm approach takes 1 or 2 seconds
>> on
>> Windows Server 2008 64-bit 16GB RAM server
>>
>> 7. outside-of-the-norm appraoch takes 10 minutes on Windows Server 2003
>> 32-bit 4GB RAM server
>>
>> 8. i consider Apache Derby a real DB while others may not. I've seen
>> benchmarks, and what I saw, Derby outperforms MySQL; only other DB that I
>> would be interested in migrating to... is HSQL DB (hyper SQL DB); i think
>> that's the one shipped with our beloved 'TomEE'... Derby has
>> excellent/perfect documentation and i am very impressed with the
>> performance of Derby on the Windows Server 2003 32-bit 4GB
>>
>> 9. 'norm' concurrent operations in my app performed very well for months
>> with JSF-managed-beans on Glassfish 3.1.2.2, and the same 'norm'
>> concurrent
>> operations in my app is performing just as well now (maybe faster) on
>> TomEE
>> (CDI-managed-beans instead of JSF managed beans)
>>
>> 10. yes, i heard/know that people like to consider Apache Derby a testing
>> database, but it's definitely my production database...performing very
>> very
>> well and very reliable; honestly, i would only replace it for even better
>> performance; most of my 'norm' concurrent operations take 2 to 3 seconds;
>> user don't have to wait long at all unless i'm retrieving a bunch of rows
>> with some complicated joins involved, oh, and then the container has to
>> 'render' that data (when user selects plenty of data from database); and
>> we
>> know that rendering can hinder performance. I found that out when i
>> migrated from glassfish to tomee... had to eliminate many of the
>> rendered="..." on the popular/frequently-used xhtml pages in the app. :)
>>
>>
>> On Thu, Dec 13, 2012 at 11:27 AM, Neale <ne...@metawerx.net> wrote:
>>
>>> How big is the DB?
>>> Do you have indexes?
>>> It should be lightning fast (1000+ requests per minute) for small DB
>>> name/address lookups.
>>> Have you tried a real DB like MariaDB/MySQL/PgSQL? Derby is pretty
>>> terrible if the database is substantial... good for testing small
>>> projects
>>> though.
>>>
>>
>
Re: DB access is very slow
Posted by Neale <ne...@metawerx.net>.
Hi Howard,
Derby is an in-memory java-based DB, so with a 100mb database it performs
great.
Once you start putting real data into it, it fails horribly. It's designed
for testing, and never for production (read the docs).
Please never use it as a "production" database. We had a customer here
using it, and after their database grew to 2gb in size it started consuming
100% CPU on multiple CPUs and displaying huge disk I/O and GC. They
converted to MySQL and their usage has dropped to less than 1% of what derby
was using.
But it's a great DB for testing small apps, and with very small apps it may
even perform faster than a real DB ;-)
Anyway, with your specific problem, for now I would recommend separating the
database and JPA so you can measure them both separately.
It's always easier to solve a problem by breaking it into smaller pieces.
Best Regards,
Neale Rudd
Metawerx Pty Ltd
www.metawerx.net
----- Original Message -----
From: "Howard W. Smith, Jr." <sm...@gmail.com>
To: <us...@openejb.apache.org>
Sent: Friday, December 14, 2012 3:48 AM
Subject: Re: DB access is very slow
> 1. In a .zip file, the Derby database is at least 17MB
>
> 2. yes, have indexes, i did that months ago after reviewing the apache
> derby tuning database PDF
>
> 3. trust me, it is lightning fast when the 'norm' code is performing
> database operations, concurrently; 'norm' code/approach = managed beans
> have @EJB, @EJB = DAO
>
> 4. the approach discussed in this email thread and other-related email
> threads, I did an outside-of-the-norm approach for my app
>
> 5. outside-of-the-norm approach = @Stateless EJB with @Schedule method()
> calls multiple @Stateless EJBs (DAO) to lookup as well as simple
> insert/persist statements
>
> 6. lightning fast? the outside-of-the-norm approach takes 1 or 2 seconds
> on
> Windows Server 2008 64-bit 16GB RAM server
>
> 7. outside-of-the-norm appraoch takes 10 minutes on Windows Server 2003
> 32-bit 4GB RAM server
>
> 8. i consider Apache Derby a real DB while others may not. I've seen
> benchmarks, and what I saw, Derby outperforms MySQL; only other DB that I
> would be interested in migrating to... is HSQL DB (hyper SQL DB); i think
> that's the one shipped with our beloved 'TomEE'... Derby has
> excellent/perfect documentation and i am very impressed with the
> performance of Derby on the Windows Server 2003 32-bit 4GB
>
> 9. 'norm' concurrent operations in my app performed very well for months
> with JSF-managed-beans on Glassfish 3.1.2.2, and the same 'norm'
> concurrent
> operations in my app is performing just as well now (maybe faster) on
> TomEE
> (CDI-managed-beans instead of JSF managed beans)
>
> 10. yes, i heard/know that people like to consider Apache Derby a testing
> database, but it's definitely my production database...performing very
> very
> well and very reliable; honestly, i would only replace it for even better
> performance; most of my 'norm' concurrent operations take 2 to 3 seconds;
> user don't have to wait long at all unless i'm retrieving a bunch of rows
> with some complicated joins involved, oh, and then the container has to
> 'render' that data (when user selects plenty of data from database); and
> we
> know that rendering can hinder performance. I found that out when i
> migrated from glassfish to tomee... had to eliminate many of the
> rendered="..." on the popular/frequently-used xhtml pages in the app. :)
>
>
> On Thu, Dec 13, 2012 at 11:27 AM, Neale <ne...@metawerx.net> wrote:
>
>> How big is the DB?
>> Do you have indexes?
>> It should be lightning fast (1000+ requests per minute) for small DB
>> name/address lookups.
>> Have you tried a real DB like MariaDB/MySQL/PgSQL? Derby is pretty
>> terrible if the database is substantial... good for testing small
>> projects
>> though.
>>
>
Re: DB access is very slow
Posted by "Howard W. Smith, Jr." <sm...@gmail.com>.
1. In a .zip file, the Derby database is at least 17MB
2. yes, have indexes, i did that months ago after reviewing the apache
derby tuning database PDF
3. trust me, it is lightning fast when the 'norm' code is performing
database operations, concurrently; 'norm' code/approach = managed beans
have @EJB, @EJB = DAO
4. the approach discussed in this email thread and other-related email
threads, I did an outside-of-the-norm approach for my app
5. outside-of-the-norm approach = @Stateless EJB with @Schedule method()
calls multiple @Stateless EJBs (DAO) to lookup as well as simple
insert/persist statements
6. lightning fast? the outside-of-the-norm approach takes 1 or 2 seconds on
Windows Server 2008 64-bit 16GB RAM server
7. outside-of-the-norm appraoch takes 10 minutes on Windows Server 2003
32-bit 4GB RAM server
8. i consider Apache Derby a real DB while others may not. I've seen
benchmarks, and what I saw, Derby outperforms MySQL; only other DB that I
would be interested in migrating to... is HSQL DB (hyper SQL DB); i think
that's the one shipped with our beloved 'TomEE'... Derby has
excellent/perfect documentation and i am very impressed with the
performance of Derby on the Windows Server 2003 32-bit 4GB
9. 'norm' concurrent operations in my app performed very well for months
with JSF-managed-beans on Glassfish 3.1.2.2, and the same 'norm' concurrent
operations in my app is performing just as well now (maybe faster) on TomEE
(CDI-managed-beans instead of JSF managed beans)
10. yes, i heard/know that people like to consider Apache Derby a testing
database, but it's definitely my production database...performing very very
well and very reliable; honestly, i would only replace it for even better
performance; most of my 'norm' concurrent operations take 2 to 3 seconds;
user don't have to wait long at all unless i'm retrieving a bunch of rows
with some complicated joins involved, oh, and then the container has to
'render' that data (when user selects plenty of data from database); and we
know that rendering can hinder performance. I found that out when i
migrated from glassfish to tomee... had to eliminate many of the
rendered="..." on the popular/frequently-used xhtml pages in the app. :)
On Thu, Dec 13, 2012 at 11:27 AM, Neale <ne...@metawerx.net> wrote:
> How big is the DB?
> Do you have indexes?
> It should be lightning fast (1000+ requests per minute) for small DB
> name/address lookups.
> Have you tried a real DB like MariaDB/MySQL/PgSQL? Derby is pretty
> terrible if the database is substantial... good for testing small projects
> though.
>
Re: DB access is very slow
Posted by Neale <ne...@metawerx.net>.
How big is the DB?
Do you have indexes?
It should be lightning fast (1000+ requests per minute) for small DB
name/address lookups.
Have you tried a real DB like MariaDB/MySQL/PgSQL? Derby is pretty terrible
if the database is substantial... good for testing small projects though.
Best Regards,
Neale
----- Original Message -----
From: "Howard W. Smith, Jr." <sm...@gmail.com>
To: <us...@openejb.apache.org>
Sent: Friday, December 14, 2012 2:17 AM
Subject: Re: DB access is very slow
Neale,
Yes, real server that I maintain, myself, definitely 4GB RAM and Windows
Server 2003 = 32bit. :)
Howard
On Thu, Dec 13, 2012 at 10:07 AM, Neale <ne...@metawerx.net> wrote:
> Hi Howard,
>
> Is this a real server (ie: real hardware), or a VPS that says it has "4gb
> RAM, 32bit"?
>
> Neale
>
> ----- Original Message ----- From: "Howard W. Smith, Jr." <
> smithh032772@gmail.com>
> To: <us...@openejb.apache.org>
> Sent: Friday, December 14, 2012 1:49 AM
> Subject: Re: DB access is very slow
>
>
>
> only queries i do is to small lookup tables... address/phone/email address
> type to get the database entity. at most, those tables have 3 to 5 rows of
> really really small data... Business, home, mobile (phone)...
>
> file database? 'Apache' Derby
>
> locks on windows... when i first developed this (few days ago), it was
> show
> Apache Derby 'lock' exceptions... hahaha
>
>
> On Thu, Dec 13, 2012 at 9:43 AM, Romain Manni-Bucau
> <rm...@gmail.com>wrote:
>
> maybe you just do too much queries and the schedul is called too
>> often...and you are on a file database right? so it locks on
>> windows...
>>
>> Romain Manni-Bucau
>> Twitter: @rmannibucau
>> Blog:
>> http://rmannibucau.wordpress.**com/<http://rmannibucau.wordpress.com/>
>> LinkedIn:
>> http://fr.linkedin.com/in/**rmannibucau<http://fr.linkedin.com/in/rmannibucau>
>> Github: https://github.com/rmannibucau
>>
>>
>>
>> 2012/12/13 Howard W. Smith, Jr. <sm...@gmail.com>:
>> > haha okay... it is primarily a file server, also has some other >
>> software
>> > running on it, another database engine (Microsoft SQL, I think, but
>> that's
>> > not my software), that database engine is accessed by client software
>> > on
>> > laptops connected to the LAN as well as remote connection (windows >
>> remote
>> > desktop connection)...
>> >
>> > outside of that...i really don't understand why @Stateless EJB
>> referencing
>> > other @Stateless EJB to perform database operations (insert into >
>> multiple
>> > tables...'long' transaction)...does 'not' perform well at all, >
>> introduces
>> > database locks when users are logged in the web app
>> >
>> > CDI/JSF 'managed bean' referencing @Stateless EJB to perform database
>> > operations has been the 'norm' in my web app, and this never introduce
>> > database locks, deadlock situation, or people seeing exceptions with
>> > eclipselink SQL in their Facesmessage after a long long wait... :)
>> >
>> > i'm going with the managed bean --> @Stateless EJB approach, just need
>> > to
>> > change around my code to do so.
>> >
>> > will keep you posted.
>> >
>> >
>> > On Thu, Dec 13, 2012 at 9:31 AM, Romain Manni-Bucau
>> > <rm...@gmail.com>wrote:
>> >
>> >> that's not the usage of the machine :p
>> >>
>> >> Romain Manni-Bucau
>> >> Twitter: @rmannibucau
>> >> Blog:
>> >> http://rmannibucau.wordpress.**com/<http://rmannibucau.wordpress.com/>
>> >> LinkedIn:
>> >> http://fr.linkedin.com/in/**rmannibucau<http://fr.linkedin.com/in/rmannibucau>
>> >> Github: https://github.com/rmannibucau
>> >>
>> >>
>> >>
>> >> 2012/12/13 Howard W. Smith, Jr. <sm...@gmail.com>:
>> >> > same machine
>> >> >
>> >> > On Thu, Dec 13, 2012 at 8:05 AM, Josﾩ Luis Cetina <
>>
>> maxtorzito@gmail.com
>> >> >wrote:
>> >> >
>> >> >> Where is your database, localhost?
>> >>
>>
>>
>
Re: DB access is very slow
Posted by "Howard W. Smith, Jr." <sm...@gmail.com>.
Neale,
Yes, real server that I maintain, myself, definitely 4GB RAM and Windows
Server 2003 = 32bit. :)
Howard
On Thu, Dec 13, 2012 at 10:07 AM, Neale <ne...@metawerx.net> wrote:
> Hi Howard,
>
> Is this a real server (ie: real hardware), or a VPS that says it has "4gb
> RAM, 32bit"?
>
> Neale
>
> ----- Original Message ----- From: "Howard W. Smith, Jr." <
> smithh032772@gmail.com>
> To: <us...@openejb.apache.org>
> Sent: Friday, December 14, 2012 1:49 AM
> Subject: Re: DB access is very slow
>
>
>
> only queries i do is to small lookup tables... address/phone/email address
> type to get the database entity. at most, those tables have 3 to 5 rows of
> really really small data... Business, home, mobile (phone)...
>
> file database? 'Apache' Derby
>
> locks on windows... when i first developed this (few days ago), it was show
> Apache Derby 'lock' exceptions... hahaha
>
>
> On Thu, Dec 13, 2012 at 9:43 AM, Romain Manni-Bucau
> <rm...@gmail.com>wrote:
>
> maybe you just do too much queries and the schedul is called too
>> often...and you are on a file database right? so it locks on
>> windows...
>>
>> Romain Manni-Bucau
>> Twitter: @rmannibucau
>> Blog: http://rmannibucau.wordpress.**com/<http://rmannibucau.wordpress.com/>
>> LinkedIn: http://fr.linkedin.com/in/**rmannibucau<http://fr.linkedin.com/in/rmannibucau>
>> Github: https://github.com/rmannibucau
>>
>>
>>
>> 2012/12/13 Howard W. Smith, Jr. <sm...@gmail.com>:
>> > haha okay... it is primarily a file server, also has some other >
>> software
>> > running on it, another database engine (Microsoft SQL, I think, but
>> that's
>> > not my software), that database engine is accessed by client software on
>> > laptops connected to the LAN as well as remote connection (windows >
>> remote
>> > desktop connection)...
>> >
>> > outside of that...i really don't understand why @Stateless EJB
>> referencing
>> > other @Stateless EJB to perform database operations (insert into >
>> multiple
>> > tables...'long' transaction)...does 'not' perform well at all, >
>> introduces
>> > database locks when users are logged in the web app
>> >
>> > CDI/JSF 'managed bean' referencing @Stateless EJB to perform database
>> > operations has been the 'norm' in my web app, and this never introduce
>> > database locks, deadlock situation, or people seeing exceptions with
>> > eclipselink SQL in their Facesmessage after a long long wait... :)
>> >
>> > i'm going with the managed bean --> @Stateless EJB approach, just need
>> > to
>> > change around my code to do so.
>> >
>> > will keep you posted.
>> >
>> >
>> > On Thu, Dec 13, 2012 at 9:31 AM, Romain Manni-Bucau
>> > <rm...@gmail.com>wrote:
>> >
>> >> that's not the usage of the machine :p
>> >>
>> >> Romain Manni-Bucau
>> >> Twitter: @rmannibucau
>> >> Blog: http://rmannibucau.wordpress.**com/<http://rmannibucau.wordpress.com/>
>> >> LinkedIn: http://fr.linkedin.com/in/**rmannibucau<http://fr.linkedin.com/in/rmannibucau>
>> >> Github: https://github.com/rmannibucau
>> >>
>> >>
>> >>
>> >> 2012/12/13 Howard W. Smith, Jr. <sm...@gmail.com>:
>> >> > same machine
>> >> >
>> >> > On Thu, Dec 13, 2012 at 8:05 AM, Jos￩ Luis Cetina <
>>
>> maxtorzito@gmail.com
>> >> >wrote:
>> >> >
>> >> >> Where is your database, localhost?
>> >>
>>
>>
>
Re: DB access is very slow
Posted by Neale <ne...@metawerx.net>.
Hi Howard,
Is this a real server (ie: real hardware), or a VPS that says it has "4gb
RAM, 32bit"?
Neale
----- Original Message -----
From: "Howard W. Smith, Jr." <sm...@gmail.com>
To: <us...@openejb.apache.org>
Sent: Friday, December 14, 2012 1:49 AM
Subject: Re: DB access is very slow
only queries i do is to small lookup tables... address/phone/email address
type to get the database entity. at most, those tables have 3 to 5 rows of
really really small data... Business, home, mobile (phone)...
file database? 'Apache' Derby
locks on windows... when i first developed this (few days ago), it was show
Apache Derby 'lock' exceptions... hahaha
On Thu, Dec 13, 2012 at 9:43 AM, Romain Manni-Bucau
<rm...@gmail.com>wrote:
> maybe you just do too much queries and the schedul is called too
> often...and you are on a file database right? so it locks on
> windows...
>
> Romain Manni-Bucau
> Twitter: @rmannibucau
> Blog: http://rmannibucau.wordpress.com/
> LinkedIn: http://fr.linkedin.com/in/rmannibucau
> Github: https://github.com/rmannibucau
>
>
>
> 2012/12/13 Howard W. Smith, Jr. <sm...@gmail.com>:
> > haha okay... it is primarily a file server, also has some other
> > software
> > running on it, another database engine (Microsoft SQL, I think, but
> that's
> > not my software), that database engine is accessed by client software on
> > laptops connected to the LAN as well as remote connection (windows
> > remote
> > desktop connection)...
> >
> > outside of that...i really don't understand why @Stateless EJB
> referencing
> > other @Stateless EJB to perform database operations (insert into
> > multiple
> > tables...'long' transaction)...does 'not' perform well at all,
> > introduces
> > database locks when users are logged in the web app
> >
> > CDI/JSF 'managed bean' referencing @Stateless EJB to perform database
> > operations has been the 'norm' in my web app, and this never introduce
> > database locks, deadlock situation, or people seeing exceptions with
> > eclipselink SQL in their Facesmessage after a long long wait... :)
> >
> > i'm going with the managed bean --> @Stateless EJB approach, just need
> > to
> > change around my code to do so.
> >
> > will keep you posted.
> >
> >
> > On Thu, Dec 13, 2012 at 9:31 AM, Romain Manni-Bucau
> > <rm...@gmail.com>wrote:
> >
> >> that's not the usage of the machine :p
> >>
> >> Romain Manni-Bucau
> >> Twitter: @rmannibucau
> >> Blog: http://rmannibucau.wordpress.com/
> >> LinkedIn: http://fr.linkedin.com/in/rmannibucau
> >> Github: https://github.com/rmannibucau
> >>
> >>
> >>
> >> 2012/12/13 Howard W. Smith, Jr. <sm...@gmail.com>:
> >> > same machine
> >> >
> >> > On Thu, Dec 13, 2012 at 8:05 AM, Josï¿© Luis Cetina <
> maxtorzito@gmail.com
> >> >wrote:
> >> >
> >> >> Where is your database, localhost?
> >>
>
Re: DB access is very slow
Posted by "Howard W. Smith, Jr." <sm...@gmail.com>.
only queries i do is to small lookup tables... address/phone/email address
type to get the database entity. at most, those tables have 3 to 5 rows of
really really small data... Business, home, mobile (phone)...
file database? 'Apache' Derby
locks on windows... when i first developed this (few days ago), it was show
Apache Derby 'lock' exceptions... hahaha
On Thu, Dec 13, 2012 at 9:43 AM, Romain Manni-Bucau
<rm...@gmail.com>wrote:
> maybe you just do too much queries and the schedul is called too
> often...and you are on a file database right? so it locks on
> windows...
>
> Romain Manni-Bucau
> Twitter: @rmannibucau
> Blog: http://rmannibucau.wordpress.com/
> LinkedIn: http://fr.linkedin.com/in/rmannibucau
> Github: https://github.com/rmannibucau
>
>
>
> 2012/12/13 Howard W. Smith, Jr. <sm...@gmail.com>:
> > haha okay... it is primarily a file server, also has some other software
> > running on it, another database engine (Microsoft SQL, I think, but
> that's
> > not my software), that database engine is accessed by client software on
> > laptops connected to the LAN as well as remote connection (windows remote
> > desktop connection)...
> >
> > outside of that...i really don't understand why @Stateless EJB
> referencing
> > other @Stateless EJB to perform database operations (insert into multiple
> > tables...'long' transaction)...does 'not' perform well at all, introduces
> > database locks when users are logged in the web app
> >
> > CDI/JSF 'managed bean' referencing @Stateless EJB to perform database
> > operations has been the 'norm' in my web app, and this never introduce
> > database locks, deadlock situation, or people seeing exceptions with
> > eclipselink SQL in their Facesmessage after a long long wait... :)
> >
> > i'm going with the managed bean --> @Stateless EJB approach, just need to
> > change around my code to do so.
> >
> > will keep you posted.
> >
> >
> > On Thu, Dec 13, 2012 at 9:31 AM, Romain Manni-Bucau
> > <rm...@gmail.com>wrote:
> >
> >> that's not the usage of the machine :p
> >>
> >> Romain Manni-Bucau
> >> Twitter: @rmannibucau
> >> Blog: http://rmannibucau.wordpress.com/
> >> LinkedIn: http://fr.linkedin.com/in/rmannibucau
> >> Github: https://github.com/rmannibucau
> >>
> >>
> >>
> >> 2012/12/13 Howard W. Smith, Jr. <sm...@gmail.com>:
> >> > same machine
> >> >
> >> > On Thu, Dec 13, 2012 at 8:05 AM, José Luis Cetina <
> maxtorzito@gmail.com
> >> >wrote:
> >> >
> >> >> Where is your database, localhost?
> >>
>
Re: DB access is very slow
Posted by Romain Manni-Bucau <rm...@gmail.com>.
maybe you just do too much queries and the schedul is called too
often...and you are on a file database right? so it locks on
windows...
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau
2012/12/13 Howard W. Smith, Jr. <sm...@gmail.com>:
> haha okay... it is primarily a file server, also has some other software
> running on it, another database engine (Microsoft SQL, I think, but that's
> not my software), that database engine is accessed by client software on
> laptops connected to the LAN as well as remote connection (windows remote
> desktop connection)...
>
> outside of that...i really don't understand why @Stateless EJB referencing
> other @Stateless EJB to perform database operations (insert into multiple
> tables...'long' transaction)...does 'not' perform well at all, introduces
> database locks when users are logged in the web app
>
> CDI/JSF 'managed bean' referencing @Stateless EJB to perform database
> operations has been the 'norm' in my web app, and this never introduce
> database locks, deadlock situation, or people seeing exceptions with
> eclipselink SQL in their Facesmessage after a long long wait... :)
>
> i'm going with the managed bean --> @Stateless EJB approach, just need to
> change around my code to do so.
>
> will keep you posted.
>
>
> On Thu, Dec 13, 2012 at 9:31 AM, Romain Manni-Bucau
> <rm...@gmail.com>wrote:
>
>> that's not the usage of the machine :p
>>
>> Romain Manni-Bucau
>> Twitter: @rmannibucau
>> Blog: http://rmannibucau.wordpress.com/
>> LinkedIn: http://fr.linkedin.com/in/rmannibucau
>> Github: https://github.com/rmannibucau
>>
>>
>>
>> 2012/12/13 Howard W. Smith, Jr. <sm...@gmail.com>:
>> > same machine
>> >
>> > On Thu, Dec 13, 2012 at 8:05 AM, José Luis Cetina <maxtorzito@gmail.com
>> >wrote:
>> >
>> >> Where is your database, localhost?
>>
Re: DB access is very slow
Posted by "Howard W. Smith, Jr." <sm...@gmail.com>.
haha okay... it is primarily a file server, also has some other software
running on it, another database engine (Microsoft SQL, I think, but that's
not my software), that database engine is accessed by client software on
laptops connected to the LAN as well as remote connection (windows remote
desktop connection)...
outside of that...i really don't understand why @Stateless EJB referencing
other @Stateless EJB to perform database operations (insert into multiple
tables...'long' transaction)...does 'not' perform well at all, introduces
database locks when users are logged in the web app
CDI/JSF 'managed bean' referencing @Stateless EJB to perform database
operations has been the 'norm' in my web app, and this never introduce
database locks, deadlock situation, or people seeing exceptions with
eclipselink SQL in their Facesmessage after a long long wait... :)
i'm going with the managed bean --> @Stateless EJB approach, just need to
change around my code to do so.
will keep you posted.
On Thu, Dec 13, 2012 at 9:31 AM, Romain Manni-Bucau
<rm...@gmail.com>wrote:
> that's not the usage of the machine :p
>
> Romain Manni-Bucau
> Twitter: @rmannibucau
> Blog: http://rmannibucau.wordpress.com/
> LinkedIn: http://fr.linkedin.com/in/rmannibucau
> Github: https://github.com/rmannibucau
>
>
>
> 2012/12/13 Howard W. Smith, Jr. <sm...@gmail.com>:
> > same machine
> >
> > On Thu, Dec 13, 2012 at 8:05 AM, José Luis Cetina <maxtorzito@gmail.com
> >wrote:
> >
> >> Where is your database, localhost?
>
Re: DB access is very slow
Posted by Romain Manni-Bucau <rm...@gmail.com>.
that's not the usage of the machine :p
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau
2012/12/13 Howard W. Smith, Jr. <sm...@gmail.com>:
> same machine
>
> On Thu, Dec 13, 2012 at 8:05 AM, José Luis Cetina <ma...@gmail.com>wrote:
>
>> Where is your database, localhost?
Re: DB access is very slow
Posted by "Howard W. Smith, Jr." <sm...@gmail.com>.
same machine
On Thu, Dec 13, 2012 at 8:05 AM, José Luis Cetina <ma...@gmail.com>wrote:
> Where is your database, localhost?
Re: DB access is very slow
Posted by José Luis Cetina <ma...@gmail.com>.
Where is your database, localhost?
El dic 13, 2012 12:27 AM, "Romain Manni-Bucau" <rm...@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." <sm...@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 <na...@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.
> > >
> >
>
Re: DB access is very slow
Posted by "Howard W. Smith, Jr." <sm...@gmail.com>.
I had research my emails for this...
Dual Core Xeon Processor 5050 2x2MB Cache, 3.00GHz, 667MHz FSB, PE 2900
Dual Core Xeon 2nd Processor 5050, 2x2MB Cache, 3.00GHz 667MHz FSB, PE 2900
2GB 533MHz (4x512MB), Single Ranked DIMMs (replaced by 4GB RAM)
80GB, SATA, 3.5-inch 7.2K RPM Hard Drive
1TB, SATA, 3.5-inch 7.2K RPM Hard Drive (installed later; database and web
app software is here)
SAS 5/i Integrated, No RAID
Windows Server 2003 R2 Standard Edition, Includes 5 CALs
Embedded Broadcom NetXtreme II5708 GigabitEthernet NIC
PowerVault 100T, DAT72 Tape Backup, 36/72GB, w/Controller Internal for
PowerEdge 2900
On Thu, Dec 13, 2012 at 1:26 AM, Romain Manni-Bucau
<rm...@gmail.com>wrote:
> 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)
>
Re: DB access is very slow
Posted by Romain Manni-Bucau <rm...@gmail.com>.
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." <sm...@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 <na...@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.
> >
>
Re: DB access is very slow
Posted by "Howard W. Smith, Jr." <sm...@gmail.com>.
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 <na...@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.
>
Re: DB access is very slow
Posted by knak55 <na...@xb4.so-net.ne.jp>.
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.
Re: DB access is very slow
Posted by "Howard W. Smith, Jr." <sm...@gmail.com>.
I came across this blog this morning, since I clearly had differences in
performance running my code on 32-bit and 64-bit platforms. read it when
you can.
Should I use a 32- or a 64-bit JVM? | Plumbr blog
http://plumbr.eu/blog/should-i-use-32-or-64-bit-jvm
On Wed, Dec 12, 2012 at 9:19 PM, Howard W. Smith, Jr. <
smithh032772@gmail.com> wrote:
> Well, there you go, 32 bit. Is the Linux environment going to be 32bit or
> 64bit with plenty of RAM?
> On Dec 12, 2012 7:34 PM, "knak55" <na...@xb4.so-net.ne.jp> wrote:
>
>> Thank you for your suggestion.
>> My application is now under development. So I use the Windows 7(32bit)
>> with
>> 2GB memory. Once the development finishes, I am going to deploy the
>> application to the Linux server environment.
>>
>>
>>
>> --
>> View this message in context:
>> http://openejb.979440.n4.nabble.com/DB-access-is-very-slow-tp4659326p4659478.html
>> Sent from the OpenEJB User mailing list archive at Nabble.com.
>>
>
Re: DB access is very slow
Posted by "Howard W. Smith, Jr." <sm...@gmail.com>.
Well, there you go, 32 bit. Is the Linux environment going to be 32bit or
64bit with plenty of RAM?
On Dec 12, 2012 7:34 PM, "knak55" <na...@xb4.so-net.ne.jp> wrote:
> Thank you for your suggestion.
> My application is now under development. So I use the Windows 7(32bit) with
> 2GB memory. Once the development finishes, I am going to deploy the
> application to the Linux server environment.
>
>
>
> --
> View this message in context:
> http://openejb.979440.n4.nabble.com/DB-access-is-very-slow-tp4659326p4659478.html
> Sent from the OpenEJB User mailing list archive at Nabble.com.
>
Re: DB access is very slow
Posted by knak55 <na...@xb4.so-net.ne.jp>.
Thank you for your suggestion.
My application is now under development. So I use the Windows 7(32bit) with
2GB memory. Once the development finishes, I am going to deploy the
application to the Linux server environment.
--
View this message in context: http://openejb.979440.n4.nabble.com/DB-access-is-very-slow-tp4659326p4659478.html
Sent from the OpenEJB User mailing list archive at Nabble.com.
Re: DB access is very slow
Posted by "Howard W. Smith, Jr." <sm...@gmail.com>.
Glad to hear eclipselink is faster. What kind of hardware and operating
system? 32 bit or 64 bit? My windows server 2008 64bit 16GB RAM development
server performs much better than my windows 2003 32bit 4GB RAM production
server.
2008 64bit 16GB RAM server inserts data in database at 2 seconds. Inserting
same data via same software on 2003 32bit 4GB RAM server takes 10 minutes.
Trying to upgrade out of the 32bit machine asap. Using jdk7 on both
servers.
On Dec 12, 2012 6:32 PM, "knak55" <na...@xb4.so-net.ne.jp> wrote:
> I'd like to make a test application I can share with you.
>
> Regarding my application, when I replaced the OpenJPA with the eclipselink
> by changing <provider> in persistent.xml and put eclipselink.jar in lib
> directory under the TomEE home directory, the performance is greatly
> improved in the last case where it took about 2000msec with the OpenJPA. It
> becomes to take nearly 0 msec for the case, though for other two cases,
> insert and update, it still takes from 300msec to 400msec.
>
>
>
> --
> View this message in context:
> http://openejb.979440.n4.nabble.com/DB-access-is-very-slow-tp4659326p4659470.html
> Sent from the OpenEJB User mailing list archive at Nabble.com.
>
Re: DB access is very slow
Posted by knak55 <na...@xb4.so-net.ne.jp>.
I'd like to make a test application I can share with you.
Regarding my application, when I replaced the OpenJPA with the eclipselink
by changing <provider> in persistent.xml and put eclipselink.jar in lib
directory under the TomEE home directory, the performance is greatly
improved in the last case where it took about 2000msec with the OpenJPA. It
becomes to take nearly 0 msec for the case, though for other two cases,
insert and update, it still takes from 300msec to 400msec.
--
View this message in context: http://openejb.979440.n4.nabble.com/DB-access-is-very-slow-tp4659326p4659470.html
Sent from the OpenEJB User mailing list archive at Nabble.com.
Re: DB access is very slow
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Hmm, weird, please stress your app and share some stacktraces.
I benchmarked hibernate/openjpa/eclipselinks and the difference was very
small.
Le 12 déc. 2012 02:48, "Howard W. Smith, Jr." <sm...@gmail.com> a
écrit :
> Hmmmm... Glassfish is bundled with EclipseLink. Why did you go with
> PostgreSQL instead of EclipseLink?
>
> I was a Glassfish3.1.2.2 user, and yes, I know that Glassfish 3.1.2.2
> database operations are very very fast. I don't know exactly what Glassfish
> does 'for you' (automatically), but I really think Glassfish optimizes
> EclipseLink for you straight-out-the-box. Remember, Glassfish and
> EclipseLink are (somewhat) under the Oracle umbrella. EclipseLink is now
> called TopLink (and shipped with Glassfish enterprise version, I think).
> So, Glassfish folks know how to optimize EclipseLink for you.
>
> Like I told you in my previous email/response, I had to tune EclipseLink
> (persistence.xml), my JPA queries, and I already tuned my database via
> indexes and unique primary key columns (that are Integer's; I didn't have
> to change that though, i went with Integer primary key columns when I
> developed the database...'before' I started coding the java apps).
>
> Per my experience, I 'had to' optimize my app for TomEE, since TomEE does
> 'not' optimize Eclipselink, automatically. You're responsible for all that.
> :)
>
>
> On Tue, Dec 11, 2012 at 8:05 PM, knak55 <na...@xb4.so-net.ne.jp> wrote:
>
> > Thank you, Romain and smithh032772,
> >
> > Based on your suggestions, I changed the <Resource> configuration in the
> > tomee.xml like the following.
> > <Resource id="jdbc/PostgreSqlDS" type="DataSource">
> > # PostgreSQL example
> > #
> > # This connector will not work until you download the driver at:
> > # http://jdbc.postgresql.org/download.html
> > JdbcDriver org.postgresql.Driver
> > JdbcUrl jdbc:postgresql://localhost/glassfish
> > UserName ********
> > Password *******
> > JtaManaged true
> > jmxEnabled true
> > LogSql false
> > InitialSize 10
> > MaxActive 100
> > MaxIdle 30
> > MaxWait 10000
> > removeAbandoned true
> > removeAbandonedTimeout 18000
> > jdbcInterceptors=StatementCache(max=128)
> > </Resource>
> >
> > I added the lines from jmxEnabled to jdbcInterceptors.
> > And I restarted the TomEE. But the performance does not change.
> >
> > I am sorry that I do not know how to check the <Resource> setting through
> > jmx. I checked the bundled tomee application, but there does not seem to
> be
> > the menu to check the parameters of the <Resource>.
> >
> > After enhancing the OpenJPA, I do not get any improvement in the DB
> access
> > performance. Incidentally I use "Build Time Enhancement" with Maven for
> the
> > Enhancement. The Enhancement seemed to be weaved, but the eclipse says
> > "Plugin execution not covered by lifecycle configuration:
> > org.apache.openjpa:openjpa-maven-plugin:2.3.0- SNAPSHOT:enhance
> (execution:
> > enhancer, phase: process-classes)" in the editor window. I do not know
> why
> > the eclipse says such a thing.
> >
> > If there is anything else I can do, please let me know.
> >
> >
> >
> > --
> > View this message in context:
> >
> http://openejb.979440.n4.nabble.com/DB-access-is-very-slow-tp4659326p4659441.html
> > Sent from the OpenEJB User mailing list archive at Nabble.com.
> >
>
Re: DB access is very slow
Posted by "Howard W. Smith, Jr." <sm...@gmail.com>.
Hmmmm... Glassfish is bundled with EclipseLink. Why did you go with
PostgreSQL instead of EclipseLink?
I was a Glassfish3.1.2.2 user, and yes, I know that Glassfish 3.1.2.2
database operations are very very fast. I don't know exactly what Glassfish
does 'for you' (automatically), but I really think Glassfish optimizes
EclipseLink for you straight-out-the-box. Remember, Glassfish and
EclipseLink are (somewhat) under the Oracle umbrella. EclipseLink is now
called TopLink (and shipped with Glassfish enterprise version, I think).
So, Glassfish folks know how to optimize EclipseLink for you.
Like I told you in my previous email/response, I had to tune EclipseLink
(persistence.xml), my JPA queries, and I already tuned my database via
indexes and unique primary key columns (that are Integer's; I didn't have
to change that though, i went with Integer primary key columns when I
developed the database...'before' I started coding the java apps).
Per my experience, I 'had to' optimize my app for TomEE, since TomEE does
'not' optimize Eclipselink, automatically. You're responsible for all that.
:)
On Tue, Dec 11, 2012 at 8:05 PM, knak55 <na...@xb4.so-net.ne.jp> wrote:
> Thank you, Romain and smithh032772,
>
> Based on your suggestions, I changed the <Resource> configuration in the
> tomee.xml like the following.
> <Resource id="jdbc/PostgreSqlDS" type="DataSource">
> # PostgreSQL example
> #
> # This connector will not work until you download the driver at:
> # http://jdbc.postgresql.org/download.html
> JdbcDriver org.postgresql.Driver
> JdbcUrl jdbc:postgresql://localhost/glassfish
> UserName ********
> Password *******
> JtaManaged true
> jmxEnabled true
> LogSql false
> InitialSize 10
> MaxActive 100
> MaxIdle 30
> MaxWait 10000
> removeAbandoned true
> removeAbandonedTimeout 18000
> jdbcInterceptors=StatementCache(max=128)
> </Resource>
>
> I added the lines from jmxEnabled to jdbcInterceptors.
> And I restarted the TomEE. But the performance does not change.
>
> I am sorry that I do not know how to check the <Resource> setting through
> jmx. I checked the bundled tomee application, but there does not seem to be
> the menu to check the parameters of the <Resource>.
>
> After enhancing the OpenJPA, I do not get any improvement in the DB access
> performance. Incidentally I use "Build Time Enhancement" with Maven for the
> Enhancement. The Enhancement seemed to be weaved, but the eclipse says
> "Plugin execution not covered by lifecycle configuration:
> org.apache.openjpa:openjpa-maven-plugin:2.3.0- SNAPSHOT:enhance (execution:
> enhancer, phase: process-classes)" in the editor window. I do not know why
> the eclipse says such a thing.
>
> If there is anything else I can do, please let me know.
>
>
>
> --
> View this message in context:
> http://openejb.979440.n4.nabble.com/DB-access-is-very-slow-tp4659326p4659441.html
> Sent from the OpenEJB User mailing list archive at Nabble.com.
>
Re: DB access is very slow
Posted by knak55 <na...@xb4.so-net.ne.jp>.
Thank you, Romain and smithh032772,
Based on your suggestions, I changed the <Resource> configuration in the
tomee.xml like the following.
<Resource id="jdbc/PostgreSqlDS" type="DataSource">
# PostgreSQL example
#
# This connector will not work until you download the driver at:
# http://jdbc.postgresql.org/download.html
JdbcDriver org.postgresql.Driver
JdbcUrl jdbc:postgresql://localhost/glassfish
UserName ********
Password *******
JtaManaged true
jmxEnabled true
LogSql false
InitialSize 10
MaxActive 100
MaxIdle 30
MaxWait 10000
removeAbandoned true
removeAbandonedTimeout 18000
jdbcInterceptors=StatementCache(max=128)
</Resource>
I added the lines from jmxEnabled to jdbcInterceptors.
And I restarted the TomEE. But the performance does not change.
I am sorry that I do not know how to check the <Resource> setting through
jmx. I checked the bundled tomee application, but there does not seem to be
the menu to check the parameters of the <Resource>.
After enhancing the OpenJPA, I do not get any improvement in the DB access
performance. Incidentally I use "Build Time Enhancement" with Maven for the
Enhancement. The Enhancement seemed to be weaved, but the eclipse says
"Plugin execution not covered by lifecycle configuration:
org.apache.openjpa:openjpa-maven-plugin:2.3.0- SNAPSHOT:enhance (execution:
enhancer, phase: process-classes)" in the editor window. I do not know why
the eclipse says such a thing.
If there is anything else I can do, please let me know.
--
View this message in context: http://openejb.979440.n4.nabble.com/DB-access-is-very-slow-tp4659326p4659441.html
Sent from the OpenEJB User mailing list archive at Nabble.com.
Re: DB access is very slow
Posted by "Howard W. Smith, Jr." <sm...@gmail.com>.
Okay, i see you discussed this earlier with someone else. :)
http://openejb.979440.n4.nabble.com/default-tomee-ds-pool-td4656531i20.html
On Tue, Dec 11, 2012 at 9:38 AM, Romain Manni-Bucau
<rm...@gmail.com>wrote:
> yep, at least
>
> Romain Manni-Bucau
> Twitter: @rmannibucau
> Blog: http://rmannibucau.wordpress.com/
> LinkedIn: http://fr.linkedin.com/in/rmannibucau
> Github: https://github.com/rmannibucau
>
>
>
> 2012/12/11 Howard W. Smith, Jr. <sm...@gmail.com>:
> > Interesting and good to know. So, are you telling me that my
> > persistence.xml configuration is useless/invalid?
> >
> > I seem to recall, when I first installed tomEE, deployed webapp, and
> first
> > tested on production server...that my config in persistence.xml was
> > wrong/incorrect, caused errors, changed it, and then it started working
> > without errors.
> >
> > So, I need to add the following in tomee.xml resource?
> >
> > jdbcInterceptors=StatementCache(max=128)
> >
> >
> >
> > On Tue, Dec 11, 2012 at 7:08 AM, Romain Manni-Bucau
> > <rm...@gmail.com>wrote:
> >
> >> you know eclipselinks doesn't manage your datasource (since that's
> >> openejb/tomee which provides it) so all the connection config of
> >> eclipselinks is useless normally (difference between JSE and JavaEE)
> >>
> >> Romain Manni-Bucau
> >> Twitter: @rmannibucau
> >> Blog: http://rmannibucau.wordpress.com/
> >> LinkedIn: http://fr.linkedin.com/in/rmannibucau
> >> Github: https://github.com/rmannibucau
> >>
> >>
> >>
> >> 2012/12/11 Howard W. Smith, Jr. <sm...@gmail.com>:
> >> > Really????
> >> >
> >> > How did I miss that when I was reading and researching performance
> >> tuning?
> >> > :)
> >> >
> >> > Hmmm, I think I already set a value related to statement cache i my
> >> > persistence.xml. Will confirm and add this as advised. thanks!
> >> >
> >> >
> >> >
> >> > the setting jdbcInterceptors is something important too:
> >> >>
> >> >> <Resource ....>
> >> >> ...
> >> >> jdbcInterceptors=StatementCache(max=128)
> >> >> ...
> >> >> </Resource>
> >> >>
> >> >>
> >> >>
> >>
>
Re: DB access is very slow
Posted by Romain Manni-Bucau <rm...@gmail.com>.
yep, at least
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau
2012/12/11 Howard W. Smith, Jr. <sm...@gmail.com>:
> Interesting and good to know. So, are you telling me that my
> persistence.xml configuration is useless/invalid?
>
> I seem to recall, when I first installed tomEE, deployed webapp, and first
> tested on production server...that my config in persistence.xml was
> wrong/incorrect, caused errors, changed it, and then it started working
> without errors.
>
> So, I need to add the following in tomee.xml resource?
>
> jdbcInterceptors=StatementCache(max=128)
>
>
>
> On Tue, Dec 11, 2012 at 7:08 AM, Romain Manni-Bucau
> <rm...@gmail.com>wrote:
>
>> you know eclipselinks doesn't manage your datasource (since that's
>> openejb/tomee which provides it) so all the connection config of
>> eclipselinks is useless normally (difference between JSE and JavaEE)
>>
>> Romain Manni-Bucau
>> Twitter: @rmannibucau
>> Blog: http://rmannibucau.wordpress.com/
>> LinkedIn: http://fr.linkedin.com/in/rmannibucau
>> Github: https://github.com/rmannibucau
>>
>>
>>
>> 2012/12/11 Howard W. Smith, Jr. <sm...@gmail.com>:
>> > Really????
>> >
>> > How did I miss that when I was reading and researching performance
>> tuning?
>> > :)
>> >
>> > Hmmm, I think I already set a value related to statement cache i my
>> > persistence.xml. Will confirm and add this as advised. thanks!
>> >
>> >
>> >
>> > the setting jdbcInterceptors is something important too:
>> >>
>> >> <Resource ....>
>> >> ...
>> >> jdbcInterceptors=StatementCache(max=128)
>> >> ...
>> >> </Resource>
>> >>
>> >>
>> >>
>>
Re: DB access is very slow
Posted by "Howard W. Smith, Jr." <sm...@gmail.com>.
Interesting and good to know. So, are you telling me that my
persistence.xml configuration is useless/invalid?
I seem to recall, when I first installed tomEE, deployed webapp, and first
tested on production server...that my config in persistence.xml was
wrong/incorrect, caused errors, changed it, and then it started working
without errors.
So, I need to add the following in tomee.xml resource?
jdbcInterceptors=StatementCache(max=128)
On Tue, Dec 11, 2012 at 7:08 AM, Romain Manni-Bucau
<rm...@gmail.com>wrote:
> you know eclipselinks doesn't manage your datasource (since that's
> openejb/tomee which provides it) so all the connection config of
> eclipselinks is useless normally (difference between JSE and JavaEE)
>
> Romain Manni-Bucau
> Twitter: @rmannibucau
> Blog: http://rmannibucau.wordpress.com/
> LinkedIn: http://fr.linkedin.com/in/rmannibucau
> Github: https://github.com/rmannibucau
>
>
>
> 2012/12/11 Howard W. Smith, Jr. <sm...@gmail.com>:
> > Really????
> >
> > How did I miss that when I was reading and researching performance
> tuning?
> > :)
> >
> > Hmmm, I think I already set a value related to statement cache i my
> > persistence.xml. Will confirm and add this as advised. thanks!
> >
> >
> >
> > the setting jdbcInterceptors is something important too:
> >>
> >> <Resource ....>
> >> ...
> >> jdbcInterceptors=StatementCache(max=128)
> >> ...
> >> </Resource>
> >>
> >>
> >>
>
Re: DB access is very slow
Posted by Romain Manni-Bucau <rm...@gmail.com>.
you know eclipselinks doesn't manage your datasource (since that's
openejb/tomee which provides it) so all the connection config of
eclipselinks is useless normally (difference between JSE and JavaEE)
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau
2012/12/11 Howard W. Smith, Jr. <sm...@gmail.com>:
> Really????
>
> How did I miss that when I was reading and researching performance tuning?
> :)
>
> Hmmm, I think I already set a value related to statement cache i my
> persistence.xml. Will confirm and add this as advised. thanks!
>
>
>
> the setting jdbcInterceptors is something important too:
>>
>> <Resource ....>
>> ...
>> jdbcInterceptors=StatementCache(max=128)
>> ...
>> </Resource>
>>
>>
>>
Re: DB access is very slow
Posted by "Howard W. Smith, Jr." <sm...@gmail.com>.
Really????
How did I miss that when I was reading and researching performance tuning?
:)
Hmmm, I think I already set a value related to statement cache i my
persistence.xml. Will confirm and add this as advised. thanks!
the setting jdbcInterceptors is something important too:
>
> <Resource ....>
> ...
> jdbcInterceptors=StatementCache(max=128)
> ...
> </Resource>
>
>
>
Re: DB access is very slow
Posted by Romain Manni-Bucau <rm...@gmail.com>.
the setting jdbcInterceptors is something important too:
<Resource ....>
...
jdbcInterceptors=StatementCache(max=128)
...
</Resource>
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau
2012/12/11 Howard W. Smith, Jr. <sm...@gmail.com>:
> knak55,
>
> First of all I find your emails interesting.
>
> After you saw these lines in eclipse console, did you see any improvement
> in dba access? If OpenJPA (automatically) weaves entities, then I think
> that is really nice, but I could not use OpenJPA (experienced some errors
> or app wasn't working right), but Romain advised me to weave my entities,
> and I still need to do that.
>
> I am not familiar with the Enhancement feature of the OpenJPA, but as
> I was able
> to see the following lines in the eclipse console, I think the
> Enhancement must have been weaved to Entity classes.
> default INFO [main] openjpa.Tool - Enhancer running on type "class A".
> default INFO [main] openjpa.Tool - Enhancer running on type "class B".
> default INFO [main] openjpa.Tool - Enhancer running on type "class C".
> default INFO [main] openjpa.Tool - Enhancer running on type "class D".
>
> I was a Glassfish3.1.2.2 user as well, and just recently migrated to TomEE
> 1.5.1. Today, I still use eclipselink as my JPA provider (see my
> persistence.xml below), but I had to do a few things in configuring my app
> and then I had to tune my JPA queries (as well as my xhtml pages) for TomEE.
>
> I see most of your concern is the performance of database updates (more
> than performance of your queries). I think Romain recommended statement
> caching; you can see that I did that in my persistence.xml below, but I
> want to 'testify' and tell you that all day yesterday (and the day before),
> I was working on this new @Stateless bean that has ONE entitymanager; for
> now, the job of this @Stateless bean is to check formmail results
> (containing data wrapped in JSON, so I could use Gson to get the data into
> a POJO), and then update at least 6 to 8 different tables. On my
> test/development server (Windows 2008 Server 64bit 16GB RAM), the entire
> 'database update' code is averaging 1 to 2 seconds in performance.
> Retrieving the email from EMAIL server (via javamail) takes the longest
> time for the @Stateless bean, but the database access is sooooo very fast!
>
> TomEE users/committers have seen me quite active in/on this user list,
> because TomEE committers helped me migrate from
> Glassfish3.1.2.2/JSF-managed-beans to TomEE/CDI-managed-beans (and yes,
> still using EclipseLink 2.3.2 JAR, placed in tomee/lib folder). In the
> beginning, my app was running soooo much faster on Glassfish, but now my
> app runs (much) faster on TomEE, after putting some work in optimizing my
> app 'for' TomEE container. :)
>
> See below. Please note that I am using NetBeans 7.2 (instead of eclipse),
> EclipseLink 2.3.2 (JAR dropped in tomee/lib folder), and recently upgraded
> to Apache Derby 10.9.x (dropped JAR in tomee/lib folder). Glassfish3.1.2.2
> comes bundled with EclipseLink 2.3.2 and Apache Derby 10.8.6.x (I think
> that's the version).
>
>
> *src/conf/persistence.xml*
>
> <?xml version="1.0" encoding="UTF-8"?>
> <persistence version="2.0"
> xmlns="http://java.sun.com/xml/ns/persistence"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xsi:schemaLocation="http://java.sun.com/xml/ns/persistence
> http://java.sun.com/xml/ns/persistence/persistence_2_0.xsd">
> <persistence-unit name="mcmsPU" transaction-type="JTA">
> <provider>org.eclipse.persistence.jpa.PersistenceProvider</provider>
> <jta-data-source>jdbc/mcmsJta</jta-data-source>
> <non-jta-data-source>jdbc/mcmsNonJta</non-jta-data-source>
> <exclude-unlisted-classes>false</exclude-unlisted-classes>
> <properties>
> <property name="eclipselink.target-database"
>
> value="org.eclipse.persistence.platform.database.DerbyPlatform"/>
> <property name="eclipselink.jdbc.cache-statements" value="true" />
> <property name="eclipselink.jdbc.cache-statements.size" value="100"
> />
> <property name="eclipselink.logging.parameters" value="false" />
> </properties>
> </persistence-unit>
> </persistence>
>
>
> *META-INF/context.xml* (do not configure JDBC resources here; Romain
> advised me of that some weeks ago)
>
> <?xml version="1.0" encoding="UTF-8"?>
> <Context antiJARLocking="true" path=""/>
>
>
> *{tomee-install-folder}/conf/tomee.xml*
>
> <Resource id="jdbc/mcmsJta" type="javax.sql.DataSource">
> JdbcDriver org.apache.derby.jdbc.EmbeddedDriver
> JdbcUrl jdbc:derby:C:/javadb/databases/mcmsdev;create=true
> UserName ***********
> Password ***********
> JtaManaged true
> jmxEnabled true
> LogSql false
> InitialSize 10
> MaxActive 100
> MaxIdle 30
> MaxWait 10000
> removeAbandoned true
> removeAbandonedTimeout 18000
> </Resource>
>
> <Resource id="jdbc/mcmsNonJta" type="javax.sql.DataSource">
> JdbcDriver org.apache.derby.jdbc.EmbeddedDriver
> JdbcUrl jdbc:derby:C:/javadb/databases/mcmsdev;create=true
> UserName ***********
> Password ***********
> JtaManaged false
> jmxEnabled false
> LogSql false
> InitialSize 10
> MaxActive 100
> MaxIdle 30
> MaxWait 10000
> removeAbandoned true
> removeAbandonedTimeout 18000
> </Resource>
>
>
>
> On Mon, Dec 10, 2012 at 8:59 PM, knak55 <na...@xb4.so-net.ne.jp> wrote:
>
>> I am not familiar with the Enhancement feature of the OpenJPA, but as I was
>> able to see the following lines in the eclipse console, I think the
>> Enhancement must have been weaved to Entity classes.
>> default INFO [main] openjpa.Tool - Enhancer running on type "class A".
>> default INFO [main] openjpa.Tool - Enhancer running on type "class B".
>> default INFO [main] openjpa.Tool - Enhancer running on type "class C".
>> default INFO [main] openjpa.Tool - Enhancer running on type "class D".
>>
Re: DB access is very slow
Posted by "Howard W. Smith, Jr." <sm...@gmail.com>.
knak55,
First of all I find your emails interesting.
After you saw these lines in eclipse console, did you see any improvement
in dba access? If OpenJPA (automatically) weaves entities, then I think
that is really nice, but I could not use OpenJPA (experienced some errors
or app wasn't working right), but Romain advised me to weave my entities,
and I still need to do that.
I am not familiar with the Enhancement feature of the OpenJPA, but as
I was able
to see the following lines in the eclipse console, I think the
Enhancement must have been weaved to Entity classes.
default INFO [main] openjpa.Tool - Enhancer running on type "class A".
default INFO [main] openjpa.Tool - Enhancer running on type "class B".
default INFO [main] openjpa.Tool - Enhancer running on type "class C".
default INFO [main] openjpa.Tool - Enhancer running on type "class D".
I was a Glassfish3.1.2.2 user as well, and just recently migrated to TomEE
1.5.1. Today, I still use eclipselink as my JPA provider (see my
persistence.xml below), but I had to do a few things in configuring my app
and then I had to tune my JPA queries (as well as my xhtml pages) for TomEE.
I see most of your concern is the performance of database updates (more
than performance of your queries). I think Romain recommended statement
caching; you can see that I did that in my persistence.xml below, but I
want to 'testify' and tell you that all day yesterday (and the day before),
I was working on this new @Stateless bean that has ONE entitymanager; for
now, the job of this @Stateless bean is to check formmail results
(containing data wrapped in JSON, so I could use Gson to get the data into
a POJO), and then update at least 6 to 8 different tables. On my
test/development server (Windows 2008 Server 64bit 16GB RAM), the entire
'database update' code is averaging 1 to 2 seconds in performance.
Retrieving the email from EMAIL server (via javamail) takes the longest
time for the @Stateless bean, but the database access is sooooo very fast!
TomEE users/committers have seen me quite active in/on this user list,
because TomEE committers helped me migrate from
Glassfish3.1.2.2/JSF-managed-beans to TomEE/CDI-managed-beans (and yes,
still using EclipseLink 2.3.2 JAR, placed in tomee/lib folder). In the
beginning, my app was running soooo much faster on Glassfish, but now my
app runs (much) faster on TomEE, after putting some work in optimizing my
app 'for' TomEE container. :)
See below. Please note that I am using NetBeans 7.2 (instead of eclipse),
EclipseLink 2.3.2 (JAR dropped in tomee/lib folder), and recently upgraded
to Apache Derby 10.9.x (dropped JAR in tomee/lib folder). Glassfish3.1.2.2
comes bundled with EclipseLink 2.3.2 and Apache Derby 10.8.6.x (I think
that's the version).
*src/conf/persistence.xml*
<?xml version="1.0" encoding="UTF-8"?>
<persistence version="2.0"
xmlns="http://java.sun.com/xml/ns/persistence"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/persistence
http://java.sun.com/xml/ns/persistence/persistence_2_0.xsd">
<persistence-unit name="mcmsPU" transaction-type="JTA">
<provider>org.eclipse.persistence.jpa.PersistenceProvider</provider>
<jta-data-source>jdbc/mcmsJta</jta-data-source>
<non-jta-data-source>jdbc/mcmsNonJta</non-jta-data-source>
<exclude-unlisted-classes>false</exclude-unlisted-classes>
<properties>
<property name="eclipselink.target-database"
value="org.eclipse.persistence.platform.database.DerbyPlatform"/>
<property name="eclipselink.jdbc.cache-statements" value="true" />
<property name="eclipselink.jdbc.cache-statements.size" value="100"
/>
<property name="eclipselink.logging.parameters" value="false" />
</properties>
</persistence-unit>
</persistence>
*META-INF/context.xml* (do not configure JDBC resources here; Romain
advised me of that some weeks ago)
<?xml version="1.0" encoding="UTF-8"?>
<Context antiJARLocking="true" path=""/>
*{tomee-install-folder}/conf/tomee.xml*
<Resource id="jdbc/mcmsJta" type="javax.sql.DataSource">
JdbcDriver org.apache.derby.jdbc.EmbeddedDriver
JdbcUrl jdbc:derby:C:/javadb/databases/mcmsdev;create=true
UserName ***********
Password ***********
JtaManaged true
jmxEnabled true
LogSql false
InitialSize 10
MaxActive 100
MaxIdle 30
MaxWait 10000
removeAbandoned true
removeAbandonedTimeout 18000
</Resource>
<Resource id="jdbc/mcmsNonJta" type="javax.sql.DataSource">
JdbcDriver org.apache.derby.jdbc.EmbeddedDriver
JdbcUrl jdbc:derby:C:/javadb/databases/mcmsdev;create=true
UserName ***********
Password ***********
JtaManaged false
jmxEnabled false
LogSql false
InitialSize 10
MaxActive 100
MaxIdle 30
MaxWait 10000
removeAbandoned true
removeAbandonedTimeout 18000
</Resource>
On Mon, Dec 10, 2012 at 8:59 PM, knak55 <na...@xb4.so-net.ne.jp> wrote:
> I am not familiar with the Enhancement feature of the OpenJPA, but as I was
> able to see the following lines in the eclipse console, I think the
> Enhancement must have been weaved to Entity classes.
> default INFO [main] openjpa.Tool - Enhancer running on type "class A".
> default INFO [main] openjpa.Tool - Enhancer running on type "class B".
> default INFO [main] openjpa.Tool - Enhancer running on type "class C".
> default INFO [main] openjpa.Tool - Enhancer running on type "class D".
>
Re: DB access is very slow
Posted by knak55 <na...@xb4.so-net.ne.jp>.
Thank you for your reply, Romain.
I use eclipselink for Glassfish and OpenJPA for TomEE.
Though I tried to change the application to use the Built Time Enhancement
for the OpenJPA on TomEE, it does not seem to change much in terms of the
performance.
I am not familiar with the Enhancement feature of the OpenJPA, but as I was
able to see the following lines in the eclipse console, I think the
Enhancement must have been weaved to Entity classes.
default INFO [main] openjpa.Tool - Enhancer running on type "class A".
default INFO [main] openjpa.Tool - Enhancer running on type "class B".
default INFO [main] openjpa.Tool - Enhancer running on type "class C".
default INFO [main] openjpa.Tool - Enhancer running on type "class D".
Incidentally each DB access call is done in a Stateless Session Bean.
If there is anything I can do, please let me know.
--
View this message in context: http://openejb.979440.n4.nabble.com/DB-access-is-very-slow-tp4659326p4659382.html
Sent from the OpenEJB User mailing list archive at Nabble.com.
Re: DB access is very slow
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Hi,
Which JPA provider in both cases?
If openjpa, did you enhance your entities (or activated deploy time
enhancement)?
Le 10 déc. 2012 07:35, "knak55" <na...@xb4.so-net.ne.jp> a écrit :
> Whenever my application access to DB through JPA on TomEE 1.5, it takes a
> lot
> of time to complete. However, when I deploy the same war file to Glassfish
> 3.1.2.2, the DB access is very fast.
> For example, when I try to update an instance like the following,
> -----
> mergedA = em.merge(a);
> em.flush();
> -----
> it takes about from 600msec to 800mesec on my desktop.
> When I try to insert an instance like the following,
> ----
> em.persist(a);
> em.flush();
> -----
> it takes about from 300msec to 400msec.
> When I try to insert two class instances which have relation each other and
> one of the class instances has relations with two another class instance
> like the following,
> -----
> A a = em.find(A.class, aId);
> B b = em.find(B.class, bId);
> C c = new C();
> c.setAttribute1(a1);
> c.setA(a);
> c.setB(b);
> a.addC(c);
> b.addC(c);
> D d = new D();
> d.setAttribute1(a1);
> d.setC(c);
> em.persist(d);
> ----
> it takes about from 1800 - 2100 msec.
>
> However when I try to do the same thing with the same war on the Glassfish
> and the same DB, it takes almost 0 msec for all cases. I do not know why
> TomEE takes such a long time to do the same things.
> Is there anything I can do for improving the TomEE's DB access performance?
>
> Incidentally I used the System.currentTimeMillis() to measure the elapsed
> times for each case.
>
>
>
> --
> View this message in context:
> http://openejb.979440.n4.nabble.com/DB-access-is-very-slow-tp4659326.html
> Sent from the OpenEJB User mailing list archive at Nabble.com.
>