On Apr 21, 2005, at 4:51 AM, Tore Halset wrote:
> I have cut down session timeout from 600 to 300 minutes. 300 is also
> fairly long, but our users want to be able to be idle for that long.
> Each session has a DataContext that I guess could hold lots of
> DataObjects.
> * Could I (from code) examine the memory usage of the session-bound
> DataContexts?
The simplest way to estimate memory use is to do
dataContext.getObjectStore().getObjects().size(). Unfortunately
"getObjects()" does access by copy, so it may defeat the purpose of
measuring memory.
Another way is to do dataContext.getObjectStore().getObjectIterator()
and then calculate a size manually.
Also I wouldn't mind a patch that adds a "size()" method to the
ObjectStore.
> * Is it possible to empty an DataContext after a havy (lots of
> objects) operation? Would it save memory?
You can simply replace a session DataContext with a fresh one (maybe
transferring a few "important" objects first). I think this is the
simplest approach.
Also there is a working but less advertised ObjectStore feature (a pair
of methods: "startTrackingNewObjects", "unregisterNewObjects") that
lets user explicitly clean up objects added between two certain points
in time.
> Is it possible (from code) to see some statistics for the
> DataRowStore? Like how full it is, how many old objects, how much
> memory etc? I think this would be a nice function?
There is a "size" method, but that's about it.
I think we may implement statistics/management extensions following JMX
approach (so called MBeans) for both ObjectStore and DataRowStore. The
new classes can reside in the "access" package, thus being able to read
protected variables (or rather we can create getters with default
access) and expose all needed statistics for an external monitoring
application without affecting public ObjectStore and DataRowStore APIs.
I used to implement a similar JMX "instrumentation" for a customer
application in the past (not Cayenne-related). A separation of an
object that collects statistics and an object that generates this
statistics allowed to avoid messing up the "core" API.
Andrus
This archive was generated by hypermail 2.0.0 : Mon Apr 25 2005 - 22:45:14 EDT