Suppose we have two classes, Person and Address, and they have nbi-directional one-to-many relationship (one person having multiple addresses). Hibernate says we use the following to add a new address to a person:

Session session = …;

Address newAddress = new Address();
Person person = session.get(…);
person.getAddresses().add(newAddress); //

I have used hibernate on 2 large projects, one where we designed the system from the ground up (hince the database was built for the object model) and another where we applied hibernate to a legacy product (thus the database had not object model design behind).

In the first project, hibernate was a nice as it did all the work for us. However, in terms of scalability, we hit a wall later once we realized how many queries it makes to keep its cache in sync with the DB. Hibernate is still there, but we had to find many work around to scale. Has someone said before on your posts, every framework have weaknesses, and finding them was not cheap for us.

On the second project, we had to throw hibernate out and move to commons.dbutils (something equivalent). We realized that mapping hibernate to a legacy database structure was difficult and hibernate did not handle it. One can argue that the design of this database was bad, but there are many “bad” design out there and we need to continue maintaning them. Nevertheless, I was committed to keep hibernate for this project until we reached a point where hibernate was throwing exception for bad code it generated. No one answered my posting on their site, so I was forced to pull it out.

Hibernate is a fine tool to get something up and running quickly and easily. However, for large scale project with high performance requirements, I am doubtful (based on my experience) of its benefits.

After verifying with some extra tests I see there is cases that is not covered; that needs to be fixed.

“// … session.createQuery(”from Order o left join fetch o.details”); …
Does each “orderline” refer to the same instance of order?”

Currently that will only work if you an ” details left join fetch details.order”.

According to me (my testing of StatelessSession) and the Hibernate docs StatelessSession operates without ANY first level cache (Aka no persistence context at all).

My definition of “Statement level persistence context” is…
A Persistence Context exists and is scoped to a single statement (for the purposes of building a consistent object graph).

e.g Execute a single query returning orders and order lines - does the object graph contain “data aliasing” (multiple instances that represent the same logical entity).

// … session.createQuery(”from Order o left join fetch o.details”); …
Does each “orderline” refer to the same instance of order?

With StatelessSession they do not (which is consistent with the doc). If it used “Statement level persistence context” they would (my definition).

That is, Hibernate StatelessSession states it has no “first level cache” as opposed to “its first level cache is scoped to a single statement”.

Hmm, interesting…

Note: I’m relating the ‘cache’ you refer to as the JPA Persistence Context.
This can be confusing in the sense that many ORM’s have another ‘global cache’.

To start with, the way I view JPA Persistence Context is….

Persistence Context has 2 functions/jobs
- Building ‘consistent’ object graphs
- in JPA used in flush to persist all ‘dirty’ persistent objects

Persistence Context has 3 levels
- Statement (my concept, not in JPA)
- Transaction
- Extended (across multiple transactions)

The way I see the issue you describe here Brian is:
Either: You’d like to not have JPA flush dirty objects automatically.
In the example, setName(”Bar”) means that Bar is used in the update.

Or: You want the query to run with “Statement level persistence context”.
In the example the query runs in the same transaction and by default there is
‘Transaction Level persistence context’. As the object is already in the persistence
context then the query returns the same instance.

It seems to me that if either of these options where available, they would
resolve the issue you described?

Note: Statement level Persistence Context is NOT mentioned in JPA or
anywhere else (that I know of). Its a concept I use.

I wrote this document on Persistence Context that may help (hopefully).
http://www.avaje.org/persistencecontext.html

Does any of that make sense?