cayenne-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Kienenberger <>
Subject Re: array-based DataObject
Date Fri, 25 Oct 2013 14:27:43 GMT
Sounds like a good idea to me.  I can't think of any downsides other
than that it will be harder to read the data structure when debugging.

On Fri, Oct 25, 2013 at 9:13 AM, Andrus Adamchik <> wrote:
> 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
> * User-facing getters and setters will work faster - array element access by index vs.
a HashMap get.
> * 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.
> Andrus

View raw message