Maybe I'm simply confused about Java's pass-by-reference semantics or the semantics of object instances, but it looks like I'm losing the values of transient fields when I retrieve an EJB3.0 entity after it's already been loaded and the transients populated.
To be more precise:
1) I'm using Hibernate's second-level cache and query cache, which is working quite well.
2) I'm retrieving a bunch of entities via a named query from the database. Their transient fields are populated during the named query via a @Postload callback (which also works quite well). Once I get those entities, I don't do a persist() on them because I haven't changed any persistent fields. The first transaction then completes, and all those entities remain in Hibernate's second-level cache.
3) In a second transaction, I do the exact same named query, which correctly finds the cached query results and returns the items out of Hibernate's second-level cache. Two things trouble me about the instances returned by that query: the @Postload callback is called for a second time, and the transient fields are cleared when I look at them.
It's plausible to me that @Postload might be defined to be called twice in this case; I imagine that those entities, while in Hibernate's second-level cache, are treated as detached and that retrieving them is putting them into the second transaction's persistence context.
I don't see how it could be correct, however, that the transient fields are cleared. Aren't these the exact same object instances that the first transaction handled, and hence shouldn't those transient fields still be populated? Why should a named query be defined to clear out all transient fields?
In short, am I misunderstanding the EJB3.0 spec or is there a bug or missing feature in Hibernate or...?
I'm working around it for now by creating my own "third-level" cache that goes out to a find() only if it can't get an object, but I'd really prefer not to do that. Thanks!
P.S. I'm using the latest sources from JBoss CVS.
- Mark
