Craig L Russell wrote:
We should start with a high level design for the web interaction. There
are basically two strategies: entity manager per request and entity
manager per session.
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.
This is what we do now and I don't see any reason to change it.
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.
We don't need to maintain object attachment though multiple requests, so
lets just not even go down that path.
-- Allen
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 of
the way rest of the roller code is written. The code calls
strategy.store() on both new and managed object. I went down the
path to
remove 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!
