On Sunday, October 5, 2003, at 04:48 PM, Andrus Adamchik wrote:
> FYI: I just checked in the code that would allow to share snapshot
> cache information between DataContexts in the same VM. First of all,
> though all unit tests pass successfully, it is still very raw, and I
> am working to address various issues, and write unimplemented pieces.
> To anyone using nightly builds of Cayenne in production (hope nobody
> does till at least Alpha of each release), if you have a choice I
> strongly recommend to avoid using the builds timestamped starting on
> October 6 and till further notice.
Here is an update on the state of the shared cache feature. A
preliminary documentation page is included in the user guide (section
4.8) and has a URL in the local build similar to
file://....cayenne/dist/cayenne-1.1-dev/doc/userguide/design/
caching.html
Everything is still very raw and I keep moving stuff around, but I got
to an important milestone - implementing a single shared cache that is
used by all DataContexts within the same VM. The important new classes
are:
DataRow - it extends a HashMap, and is now used internally everywhere
in Cayenne. We used the terms "data row" and "snapshot" before. Now
both are formalized in a DataRow class ("snapshot" being a description
of one of the uses of DataRow, and still used informally). Lots of
deprecated API you'll see results from the fact that I changed method
signatures to take/return DataRow instead of a Map. The most important
property of DataRow is that it has a VM-unique "version", making it
useful in caches.
Question: Since after DataRow is initially created it is used as an
immutable fixed size map that should be optimized for read, is there a
better optimized superclass than HashMap? Recommendations?
DataRowStore - a shared cache for DataRows. It is totally decoupled
from the cache implementation it uses (right now it is joCache, but it
does not have to be). DataRowStore has two important properties that
need to be taken into account when using it : (1) Any snapshot
(DataRow) can "disappear" from the store at any moment in time (e.g.
when it expires), and (2) any snapshot can be replaced by a newer
version at any moment in time. This and other things (read the docs
page mentioned above) dictated the redesign of the ObjectStore that
uses DataRowStore, and also forced me to change my initial design
relying on SnapshotEvents as a primary mechanism of ObjectStore change
notifications. Right now SnapshotEvents are optional, and explicit
synchronization mechanism is implemented.
Things to do:
1. Remote notifications
2. Appropriate synchronization of DataRowStore and ObjectStore.
3. Make all the DataRowStore parameters configurable (eventually - at
the project level, editable in the Modeler)
4. Test it in a multiuser environment.
Enjoy ;-)
Andrus
P.S. On a side note, I upgraded commons.lang and ashwood jars to the
latest stable versions.
This archive was generated by hypermail 2.0.0 : Mon Oct 20 2003 - 02:28:53 EDT