Remember the "buy a Mac" commercials? When (in the commercial) the Keynote Speaker's presentation was critically interrupted by a Windoz crash, and failure to continue and causing a delay in the presentation, people in the audience were suggesting all sorts of trial solutions one after another (try the registry, try rebooting, ...), so one guy yelled out "Buy a Mac".
Funny ... but as a Project Management pattern, this "humor" could be applied to solving Hibernate issues (that may be do as much to philosophical belief system as technical inadequacies). The new satirical non sequitur, in the context of "fixing Hibernate issues", might be "Download Cayenne". :) On Mar 29, 2012, at 11:24 AM, Ashley Aitken wrote: > > Just jumping in here but this may also be interesting to consider given the > discussion so far: > >> Why can't Hibernate just load objects on demand? >> Every month someone has the idea that Hibernate could instead of throwing a >> LazyInitializationException just open up a new connection to the database >> (effectively starting a new Session) and load the collection or initialize >> the proxy that has been touched on-demand. Of course, this idea, while >> brilliant at first, has several shortcomings that only appear if you start >> to think about the consequences of ad-hoc transactional access. >> >> If Hibernate would, hidden from the developer and outside of any transaction >> demarcation, start random database connections and transactions, why have >> transaction demarcation at all? What happens when Hibernate opens a new >> database connection to load a collection, but the owning entity has been >> deleted meanwhile? (Note that this problem does not appear with the >> two-transaction strategy as described above - the single Session provides >> repeatable reads for entities.) Why even have a service layer when every >> object can be retrieved by simply navigating to it? How much memory should >> be consumed by this and which objects should be evicted first? All of this >> leads to no solution, because Hibernate is a service for online transaction >> processing (and certain kinds of batch operations) and not a "streaming >> objects from some persistent data store in undefined units of work"-service. >> Also, in addition to the n+1 selects problem, do we really need an n+1 >> transaction and connection problem? >> >> The solution for this issue is of course proper unit of work demarcation and >> design, supported by possibly an interception technique as shown in the >> pattern here, and/or the correct fetch technique so that all required >> information for a particular unit of work can be retrieved with minimum >> impact, best performance, and scalability > > from https://community.jboss.org/wiki/OpenSessionInView > > Cheers, > Ashley. > > > -- > Ashley Aitken > Perth, Western Australia (GMT + 8hrs!) > Social (Facebook, Twitter, Skype etc.): MrHatken > Professional (LinkedIn, Twitter, Skype etc.): AshleyAitken > >
