In discussing the new metamodel, John and I came to a discussion of
entity modes and how to represent them which invariably leads to a
discussion of how to handle them in the runtime apis. We initially
threw the current set up together in a rush to be quite honest and just
assumed a better design would present itself as people started using the
entity modes. That unfortunately has still not come to fruition.
The current design was chosen for a single reason, to try and share as
much information as possible between these entity modes. However, in
retrospect, I think it comes with some severe drawbacks as well as not
really living up to the hope of sharing as much as we thought. As far
as sharing, yes we are able to share second level cache providers and
connection providers and other SessionFactory-level stuff. However,
even though we share cache providers we still cache different
representations of the data separately per entity mode which is quite
dangerous since we do not invalidate across the entity modes currently.
Also, the whole idea of sharing JDBC resources is kind of dubious. What
happens if you update the same entity differently in 2 different entity
modes during the same transaction? Chaos! Thats what ;) Seriously
though, its problematic because you could have "last write wins" issues
within the same transaction between the different entity modes.
So what I propose is that we limit a SessionFactory to a single entity
Another option is to say that we go to the SessionFactory to get our
different EntityMode-based Sessions as opposed to having the Sessions be
"linked". This options lets us still share what is shareable. This
still leaves open the possibility of "last write wins" problems in JTA
Of course all this situations only occur where apps are using multiple
entity modes simultaneously, which we are not even sure is widely used;
I, at least, am not really sure exactly how entity modes are commonly
used. I know people use the dynamic map mode for integration with
scripting languages and such, but beyond that I am not sure TBH.
Steve Ebersole <steve(a)hibernate.org>
I would like to suggest an integration of Hibernate Search with Bobo Browse
(http://code.google.com/p/bobo-browse/). Bobo Browse is the open source
faceting engine developed by LinkedIn and AFAIC it's amazing. Even though
the documentation is sparse, the results are easy to achieve, flexible and
It has one caveat, it relies on another open source project: Zoie to achieve
real time updated index/search results as by default it just opens an
IndexReader and is oblivious to changes in the underlying index until
I've been looking at a way to have Hibernate Search manage the interaction
with the Index in order for Bobo to have updated results as the underlying
index changes (just like Zoie does). But frankly, I'm not too good at this
lower level stuff.
Anyway, would love to see this integration happen or some pointers on good
ways how to achieve this.