The book references the open session in view pattern as a way to avoid LazyInitializationException when working with objects that use lazy loaded references in the web tier. Having come off a project that used a toplink persistence layer, we never saw this kind of exception despite using objects with indirect collections (i.e. lazy loading) outside of a session. In researching it, I came across this link:
http://forums.oracle.com/forums/thread.jspa?messageID=1156471&#1156471
which suggests toplink avoids this situation by using an object-based secondary cache (versus hibernate's row-based "L2" cache) .

Are the facts as stated correct? It seems like this is a fairly significant difference between toplink and hibernate--that is, you have to be more careful regarding lazy initialization with hibernate.

Do not have time to read the Oracle thread but clearly, if you share instances through a global cache, threads need to be synchronized when they access that cache. This is maybe OK as an option (you can simulate this in Hibernate with a single Session, some desktop apps would do that). But definitely not good in concurrent OLTP, or most web applications. Also see the Caching In Theory chapter of the JPwH book.

My impression (and experience with the toplink app we produced, which does handle concurrent OLTP) is that toplink avoids lazy initialization problems even in this type of app.

I'll check out that chapter. Thanks.

The difference seems to be (never used Toplink, 5 years ago their workbench app crashed on me after 2 minutes into the trial) that Toplink has configurable identiy scopes on a per-entity basis. You can configure if it is transaction/session scoped or application scoped.

So Toplink application code then probably needs to be aware which entity instance is handled in which mode. Hibernate avoids this with a fixed session scoped object identity guarantee. Nothing is free, I would probably argue that "keeping the Session open as long as I need it" is easier to code and understand.

I do not think that a synchronized thread-shared global cache has a performance (and certainly not scalability) advantage, compard to the two level caching architecture of Hibernate.

But this is just me guessing, you will have to talk to someone who has used both products.