Using JDO in a Servlet container/app server

Question

Hi,
I was just wondering what Solarmetric recommends when using Kodo in a
servlet container/app server. Specifically the following:
1. Should each user session maintain a PersistenceManager or should the
PM be created per request? I am thinking it might be expensive to
maintain PMs across requests since you may have idle sessions and the
PMs may hold database resources? But since PMs aren't pooled in Kodo is
creating/closing a PM per request expensive or is it offset by Kodo's
connection pooling?
2. Is it advisable to store data to be displayed on a JSP by storing the
JDO instances themselves or serializable proxies (simple data beans) of
these objects in a user's session?
3. If you can store the JDO instances in the session, do you need to
make them transient instances using makeTransient() and call close() the
PersistenceManager?
Thanks in advance,
Khamsouk

Answer 1

These are all very good questions. There really is no one right answer to any
of them, so I'll just try to educate you on the issues involved and you can
make your own decision. Hopefully other people who are actually using Kodo
in a servlet/JSP environment will chime in too.
1. Should each user session maintain a PersistenceManager or should the
PM be created per request? I am thinking it might be expensive to
maintain PMs across requests since you may have idle sessions and the
PMs may hold database resources? But since PMs aren't pooled in Kodo is
creating/closing a PM per request expensive or is it offset by Kodo's
connection pooling?As long as you are outside of a datastore transaction, a PM does not maintain
any database resources. The only significant state it maintains is a soft
cache of persistent objects that have already been instantiated. If you are
using Kodo 2.3 RC1 and have no set the
com.solarmetric.kodo.DefaultFetchThreshold property to -1, then some
large collections you obtain from query results or relation traversals may be
scrollable result sets on the back-end, in which case they obviously maintain
some database resources.
2. Is it advisable to store data to be displayed on a JSP by storing the
JDO instances themselves or serializable proxies (simple data beans) of
these objects in a user's session?
3. If you can store the JDO instances in the session, do you need to
make them transient instances using makeTransient() and call close() the
PersistenceManager?I'll address these together. JDO fully supports serialization, and in fact
I think you'll find it does so in exactly the way that you want. If you choose
to store serialized persistent objects in the session, then during
serialization the objects will transparently pull in all of their persistent
state and relations, so the entire object graph is serialized. When you
deserialize, the objects will no longer be attached to their persistence
manager -- they will be transient.
Another options is to store the object IDs in the session, and re-retrieve
the persistent objects for each web request.
One design pattern that can probably net very good performance is to maintain
a global read-only persistence manager that you use to dereference these IDs.
Of course, if you ever want to change an object, you'll have to re-fetch it
in a new persistence manager, and evict it from the global manager's cache.
I hope this helps.