JDO, KODO problems

[hucmuc]

We've started using solermetrics Kodo for the JDO implementaton.

I'm surprised at the gotchas with it. Hopefully, someone can clarify the following issues.

The first problem is with the persistent manager. If I do.:

UserManager usrmgr = appcontext.getBean("usermgr";
User user = usrmgr.getUser("toto");

System.out.println(user.getFirstName());

Kodo throws an exception when user.getFirstName() since it needs a persistent manager open. How does one make this transparent? JDO seems to imply that you should not use domain objects but to convert them to value holder objects before returning them (back to entity bean days). Is this correct?

I'm VERY surprised about this since Rod advocates JDO and hibernate (btw I had no problems with hibernate). Having to worry about the persistent manager on the client side seems to break the persistence transparency. Plus to have the persistent manager OPEN while outside the facade calls seems to imply some overhead for each method call on the domain object (seems like deja vu with entity beans).

Support says to use the detach method which really annoys me since it is not standard and the ONLY reason we chose JDO is that it was a standard. The detach methods basically clones the object.

I have read a couple of articles saying that JDO is not really appropriate for web based application. Is this true?

How does one use JDO in a transparent and productive way in a web based application?

dino

[Juergen Hoeller]

Indeed, JDO has quite rigid state handling: You either need to detach objects if you want to use them outside of a DAO operations, which is about to be standardized in JDO 2.0, or you need to keep the PersistenceManager open. You cannot simply use persistent objects anywhere, in contrast to Hibernate.

Spring explicitly supports the latter through its OpenPersistenceManagerInViewFilter/Interceptor, analogous to the Hibernate support: You'll get one PM per HTTP request then, with all Spring-managed transactions automatically using that PM. Lazy loading will even work in views, as the PersistenceManager is still open then.

From the point of DAO implementations, simply code the as usual, without detachment: The instances will automatically stay alive as long as the PersistenceManager is open, i.e. for the scope of the entire request. You need to detach if you want to put persistent objects into the HttpSession or the like, though.

Juergen

[hucmuc]

The only problem is that the filter will open a persistent manager REGARDLESS if I call a jdo function or not which doesn't sit easy with me.

Is opening a persistent manager a major overhead? Or is it insignificant? What about high traffic?

Thanks for your input.

Dino

[Juergen Hoeller]

A PersistenceManager is quite lightweight object: It won't allocate any resources on creation, but rather lazily fetch them when actually needed. So an open PersistenceManager does not hold a JDBC Connection if it didn't do any database access yet.

This is similar to the Hibernate Open Session in View pattern: Even Gavin himself says there is not much point in lazily creating a Session, because a Session does not hold a JDBC Connection unless needed, so it's not worth the effort.

As a side note, the Open * in View pattern is actually more appropriate for JDO than for Hibernate: In case of a transaction rollback, all modified objects will be reset too along with the database. So you should usually never face an inconsistent PersistenceManager.

Note that you can map OpenPersistenceManagerInViewFilter/Interceptor to more specific URL patterns, so that they just apply to requests that at least potentially perform data access. I.e. don't map it for paths that include images and co too.

Juergen

[hucmuc]

Thanks Juergen for the explanation.

Quick design question. Would you use the "detach" method as a means to clone the object before returning it to the web layer or use the OpenPersistenceManagerInViewFilter?

Dino