I read the Sticky topic at the top of this forum before starting this topic.
A Sticky would definitely have helped me.
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4064784#4064784
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&m
I had googled for it and searched the forums, but had not chosen the right
search terms.
I think it would be good for such a major change to be highlighted in bold at
the start of the readme.html.
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4064375#4064375
Yes I read it, but obviously not carefuly enough.
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4064169#4064169
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4064169
___
jbos
In this scenario there is no advantage in using multiple entity managers, so
you should let the container handle it.
If anything, in this scenario the use of multiple entity managers may slow down
your app as it may mean updates / deletes are flushed more frequently than they
need to be.
I sug
I am evaluating ejb3 and looking at the standard case of where an entity is
read from the DB in one transaction, modified, then changes saved in another
transaction.
When em.merge() is called for the detached entity, EJB3 is implicitly executing
a select against the DB for that entity.
Is ther
Setting hibernate logging to WARN does help but there is still a signficant
performance difference.
Here are the elapsed times with 20 consecutive selects each returning 5000
different rows (averaged over 3 runs excluding the 1st run). Hibernate logging
set to WARN.
createQuery(hsql): 11088ms
Following your suggestion, I tried setting FlushModeType to COMMIT (the only
other value supported with EJB3) as follows, but the query is as slow as before.
| public List< TestData > select( int accountId, Timestamp timeScheduled
) {
| Query query = em.createNativeQuery( "s
I am comparing the performance of EJB3/Hibernate with straight JDBC calls.
There seems to be an issue with the EJB3 code that maps the result set to the
returned list of POJOs.
In a test of 20 threads each selecting 5000 rows, I am finding that EJB3 is
about 3 times slower than the JDBC code (o
