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 mode. 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 scenarios. 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 <st...@hibernate.org> http://hibernate.org _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
