We've further investigated into this problem and finally found the reason for the bad query performance: The reason seems to be related with the FlushModeType.The default FlushModeType.AUTO requests the appserver to make all updates of a transaction visible to subsequent queries within the same transaction (ejb-3_0-fr-spec-persistence.pdf, chapter 3.6.2 Queries and Flush Mode). Exactly this seems to become a performance problem for JBoss as soon as the number of queried EntityBean-POJOs within a transaction starts growing in the PersistenceContext. When we either clear the EntityManager after each query operation within the transaction (em.clear(), which is not really feasible under many circumstances) OR when we set the FlushModeType.COMMIT (which is also NOT what we normally need, we expect to work with the EJB3 default FlushModeType.AUTO), the performance for queries within a transaction is constant (Performance OK, but NOT the required functionality with em.clear() or FlushModeType.COMMIT). With FlushModeType.AUTO the performance is progressively decreasing, even if only 1000 EntityBean POJO's have been read within the transaction. Just to recall the difference again: 20 queries/reads within transaction - 10 msecs average per query/read 1000 (same as before) queries/reads - 130 msecs average per query/read (factor 13+) This can't be OK! Possibly we need to do some specific JBoss configuration? Otherwise I tend to report this a a bug on JIRA, because such a significant performance downgrade can't be by intend or by design? Thanks for any feedback as to how we should best proceed with this problem. Andreas View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3957377#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...