cayenne-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrus Adamchik <>
Subject array-based DataObject
Date Fri, 25 Oct 2013 13:13:05 GMT
Been thinking about it for a long time. Now finally had a quiet vacation moment to put my thoughts
in an email.. This is about CayenneDataObject structure (or rather an alternative to it).
Each CDO is really a wrapper around a HashMap. A HashMap gives flexibility to store anything
we want, but it is also a heavy and thread-unsafe structure. One of the reasons we designed
ivar-based PersistentObject for ROP was to avoid sending serialized HashMaps across the wire.
However ivar-based design has its own shortcomings in an ORM. E.g. you can't store faults
in ivars of a fixed type. Also keeping the entire object state in one data structure that
is not a DO itself will allow to implement some other improvements I am considering (this
is a topic of another discussion - I am thinking of atomically swapping object state to improve
DataContext select concurrency) 

So I am thinking of creating an entirely new DataObject superclass based on fixed-size array
with properties accessed by numeric index. The idea is similar to java.util.EnumMap: A set
of persistent properties for each entity is known and fixed. Sorting properties alphabetically
gives us an index of each value in the object values array. This index can be stored in property
descriptors, and used in generated object code. Array-based DataObject will have the following

* It is internally consistent without any synchronization, i.e. unlike HashMap it won't fall
apart when modified by multiple threads.
* It is compact. Unlike HashMap there's no Entry<K,V> objects, and no multi-bucket strcuture.
As a result each DataObject will take less memory, and produce smaller serialized footprint.
* User-facing getters and setters will work faster - array element access by index vs. a HashMap
* Don't see any reason why we can't use it on the ROP client, so we may achieve our long-term
goal of unifying client and server stacks.
* Object state can be cloned in a consistent manner and can be swapped atomically - something
that may be important for the future context concurrency work.

Comments are welcome.

View raw message