Andrus Adamchik <andru..bjectstyle.org> wrote:
> Then how about turning off shared cache all together ("Use Shared Cache"
> checkbox for DataDomain). This will put Cayenne in a "1.0 mode" with each
> DataContext having its own cache. This way new DataContexts will start
> empty, and will be filled with fresh data as you run queries or resolve
> relationships.
>
> [Also if you go with this option, I suggest reducing "max number of
> objects" for the DataDomain cache from 10000 to something smaller, as this
> will now be multiplied by the number of DataContexts].
This is the strategy I currently have implemented: If I detect an external
change, I invalidate all objects.
dataContext.invalidateObjects(dataContext.getObjectStore().getObjects());
I perform this check in
DataContext aDataContext =
CustomBasicServletConfiguration.getDefaultContext(request.getSession());
which I now use instead of BasicServletConfiguration.getDefaultContext().
This has the advantage of "updating" a live session at every web request
(and it should only happen once a day). I'm not sure of the implications
of one session invalidating objects in all other active sessions. Reading
the source indicates that new objects won't be touched, but makes me think
that any changes in a modified object would be lost. Would this be true?
Your idea of completely non-shared data contexts is an interesting one. My
concerns would be that the data would never be updated for long-running
sessions (our administrative users are generally logged as the same session
all day). I'm also unclear what would happen when I import an object from
another session using context.localObjects(). I'm guessing that there'd be
no guarantee that the object reflected what was in the database?
Maybe for my needs, a combination of these techniques makes the most sense.
Use a non-shared data context, then invalidate all objects in that context
when changes are detected as the first step in retrieving a session's
DataContext. I'm fairly certain that I never make a change during a
request/response cycle without either committing or rolling back that change
before sending back a response.
Thanks. You've given me a new strategy to consider which has some
unexpected benefits (guarantees that after sessions expire, all database
objects are "garbage collected").
-Mike
This archive was generated by hypermail 2.0.0 : Mon Nov 22 2004 - 14:43:46 EST