Hi,
I am using Hibernate's JPA implementation in a J2SE application. I am using an application-managed EntityManager and an EXTENDED persistence context. I chose to set the flush mode on the EntityManager to COMMIT. I am also using a resource-local transaction returned by the EntityManager.

During the transaction, I persist some newly created entities. But when I use native queries to search for these newly created entities, I get nothing back.

Correct me if I am wrong, but once an entity is persisted, any query (native or not) through the EntityManager should first examine the persistence context and then the database. If so, why isn't this the case for my example. For the record, I am using SELECT statements to look up the newly created entities and the look-ups are not based on the primary keys.

Any help would be appreciated.

I am not familiar with JPA or EntityManager, but in "plain" Hibernate a query will only look in the database. The default flush mode (AUTO) usually takes care of this by flushing new entities to the database before executing the query. Have you tried setting a different flush mode or calling session.flush() manually?

Thank you Norbord for your reply.
The reason why I chose to use the COMMIT flush mode is because the AUTO mode is terribly inefficient for my application. There are far too many queries issued, the results of which are often already held in the persistence context.

I don't know what algorithm hibernate uses internally but it seems that the persistence context is bypassed entirely when looking up entities using queries (native or not). In my case the size of my result set is 1 and most of the time the persistence context alone is sufficient to honour the queries without having to go to the database. Why not use the persistence context in this instance? What flush it to the db

I don't think this is as easy as you might think. The goal for such a functionality would of course be to return an identical result weather or not the session has been flushed before the query.

For simple queries only involving a single entity class it might be possible. Then, consider more complex queries involving joins, aggregate functions, grouping, order by, etc. Even if it was possible to search in the persistence context the result would then have to be merged with the result from executing the same query on the database. The merge would of course have to consider entities that have been updated in the persistence context but not yet flushed to the database. I just think it is a too complex task to be possible to implement.

I agree that the AUTO flush mode may be inefficient and we are using the MANUAL mode ourselves. In my case I discovered this when we needed a batch update functionality that could updated several thousands of items from a text file. Each item had to be found in the database using a query. It was fast to begin with but slowed down considerably after a few thousand items. The reason was that Hibernate was spending most of the CPU time with automatic dirty checking on all previously loaded objects as part of the flush that happened before each execution of the query. The best solution for us was to use the MANUAL flush mode and then flush and commit everything when all objects had been updated.