Does anyone have some experiences to share with regard to using the 'open session in view' pattern with OpenJPA?
My application uses a small number (1 or 2) of large root entities. Large as in 20+ tables, depth 10+ including several OneToMany assocations between root and leaves, that are 'wide' in terms of rows. Typically, the front end (JSF) needs to load only a fraction of the entire graph. The application detaches root entities before passing to the web tier (actually an EJB service layer which provides operations that return entities, to the web tier). This leads to issues because fetching the entities eagerly does not scale well due to their size, but fetching them non-eagerly also leads to issues because it cannot be predicted at fetch time (and therefore implemented with a fetch plan) which parts of the graph the application will ever need. Also, some developers are concerned that a given entity does not have consistent behavior (ie non-obviously and depending on how it was loaded, certain attributes are not available). OSIV would address some of these issues. The web tier would have unfettered access to any part of the graph of the entity, without having to load it eagerly. Back end developers would not have to come up with a myriad of fetch plans to try and keep ahead of what the front end will need. The implementation would be that the web session holds a stateful EJB session bean, that holds an extended PersistenceContext, for the duration of a web 'conversation' A conversation might consist of viewing parts of the graph, and for update scenarios, filling up a bunch of forms over a series of half a dozen or so client request/response interactions, and then starting and committing a transaction to flush the root entity and closing the bean and the it's PC. What are the pros and cons of using OSIV? Here are some of the concerns we've heard from our architects and developers. - It may be difficult to cleanly demarcate the scope of the 'conversation' in the web tier. (Note, not transaction scope, as the conversation can span multiple transactions, or no transactions for a view-only use case). - Excessive resources might be consumed as fetched entities are held in the PC for the entire conversation, and/or that backend connections to the database would be held. - If JSF views are bound to 'live' (managed) entities, the database might be updated 'accidently'. - OSIV would not be applicable when distributing layers across different machines. Pros - Front end has unfettered and transparent access to entire graph with no (eager-fetching) 'charge', and entities are consistent in their behavior. - Closing the conversation (with rollback of any open transaction) can be done automatically on session timeout; sessions can be kept short; application can force the user to commit or cancel an open transaction and not leave the session open indefinitely. - Footprint may actually decrease. The root entity is held by the http session anyway, so adding a reference in the PC would not increase it. In fact, with lazy fetching, only the root entity needs to be present, and only the actual working set will be faulted in, which is often just a fraction of the full entity. - No more trying to code fetch logic for a myraid of possible hydration levels of the entities trying to predict what the front end will ever need - Having an open PC does not necessarily imply that backend database connections or other resources are held (?) - No merging/reattaching, and concomitant refetching of entities on update - Flushing or committing does not happen accidently, a transaction must be started and committed to update the database. - We have no current requirement for distributed tiers. Anyway, using managed does not preclude fetching eagerly and detaching, if and when required. Any other major concerns with OSIV? I'm interested in any success stories using managed entities in the web tier and/or solutions to the issues raised above, as well as any cites in the literature or the spec that support the OSIV pattern as a best practice for addressing the detachment 'problem'. So far we are familiar with Linda Demichiels and Gavin Kings presentation in JavaOne 2006 (TS-1887) as well as Mike Keith's 'Transaction view' example in the book, Pro JPA 2. (As Mike states therein, "the only complete solution to any detachment scenario is not to detach at all"). -- View this message in context: http://openjpa.208410.n2.nabble.com/Avoiding-detachment-aka-Open-Session-in-View-tp6618821p6618821.html Sent from the OpenJPA Users mailing list archive at Nabble.com.
