Entity manager per request: A new EM is obtained for each request. Entities that are retrieved from the database are detached at the end of the request. These entities are used to send data to the user, and the data comes back later in a subsequent request. The backing beans are merged into the new entity manager for the request. Changes from the web request are applied to the entities and are committed to the back end. The big challenge with this approach is the requirement to merge the entities at the beginning of each web request.
Entity manager per session: A new EM is obtained for the session. Entities that are retrieved from the database are kept associated with the EM at the end of the request. These entities are used to send data to the user, and the data comes back later in a subsequent request. The backing beans are still associated with the EM when the next request comes. Changes from the web request are applied to the entities and are committed to the back end. The big challenge with this approach is the serialization requirement of the EM, which is currently not specified by JSR 220. We would need to find an implementation of the spec that supports serialization of the EM and adhere to its (non-standard) behavior.
Craig On Jan 11, 2007, at 1:46 PM, Allen Gilliland wrote:
Dave wrote:On 1/11/07, Mitesh Meswani <[EMAIL PROTECTED]> wrote:It might not be easy to entirely get rid of PersistentObject because ofthe way rest of the roller code is written. The code callsstrategy.store() on both new and managed object. I went down the path toremove reference to PersistentObject while implementing JPAPersistenceStrategy but had to revert back. See comments in JPAPersistenceStrategy#store for more information.Yes, it will require a fair amount of code changes but I think it's the right thing to do and I've got time to tackle it now so I'm going to take shot.I haven't looked at it very carefully, but I would think that the main culprits are the struts actions which often create a new pojo and load it with data from the submitted form (including id) rather than querying for an object and then mutating it's properties. It'll be a fair amount of work to tidy that up, but it's important.-- Allen- Dave-Mitesh Dave wrote:> I'm working with Craig and Mitesh this week, helping to get their JPA> implementation up and running. I'm running into some issues: >> 1 - The JPA implementation doesn't include the new Planet interface> 2 - The Planet POJOs no longer extent PersistentObject > 3 - The Roller POJOs still do > > Working on code for #1 I've found that #3 makes things a little > painful. So in my workspace now, I'm working on eliminating the> PersistentObject class entirely and replaced the kludgey store () and> remove() code in HibernatePersistenceStrategy with nice clean > implementations (like the one in Planet's strategy). > > Any objections to eliminating PersistentObject? > Any other ideas or suggestions? > > - Dave
Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp!
smime.p7s
Description: S/MIME cryptographic signature
