On Jun 6, 2009, at 9:22 PM, Joe Baldwin wrote:
Question:
In a JSP webapp scenario with sessions, it appears that each session
gets its own ObjectContext (via getThreadObjectContext()). If this
is true, then, for example with an ECommerce site with a Product
abstraction, if one user queries Cayenne for a list of Products,
and then a second user makes the identical request are there
ultimately two data objects created for each Product or just one
data object?
My expectation used to be that there was one data object for each
Product, but given my reading, it appears that there are two. If
there are two, and I really want just one, should I start
implementing some sort of query caching?
It is up to you how you configure the context scope (application,
session, request, or any other that makes sense in your app), and
whether your app will or will not share the objects. Here is a bit of
explanation on the common choices. Not sure if it will answer all your
questions, but it seems like a needed prerequisite to this discussion.
Each context has its own distinct set of objects (something you've
observed), so users of different contexts will not see each other's
changes until those are committed, and even worse, won't be able to
edit the same uncommitted DataObjects in parallel (note that
ObjectContext is thread safe, but DataObjects are not).
In a read-only application (or read-only parts of the application) you
can use a single shared ObjectContext (application scope). It will be
thread-safe, fast and have a low memory footprint. If your application
modifies data, you have to use dedicated contexts. The easiest
scenario is one per session, however there are some variations. E.g.
to improve concurrency and reduce memory use, you can use one context
per request, or even one per single data modification. You can also
combine a single shared "read-only" and dedicated read-write contexts
created on the spot... Again, using a session context is a reasonable
default, but from there you need to analyze your application needs and
make a decision on an appropriate config.
Andrus
