FAQ
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 properties/advantages:

* 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 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

Search Discussions

  • Mike Kienenberger at Oct 25, 2013 at 2:28 pm
    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 properties/advantages:

    * 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 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
  • Michael Gentry at Oct 25, 2013 at 3:18 pm
    Are you planning on still supporting key paths (readProperty,
    readNestedProperty, etc)?

    Also, I'm assuming the constants for the array index would be generated in
    the _Class. We might need to look into the serialVersionUID issue again,
    too, because this seems more fragile between versions to me.

    Thanks,

    mrg


    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 properties/advantages:

    * 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 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

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupdev @
categoriescayenne
postedOct 25, '13 at 1:13p
activeOct 25, '13 at 3:18p
posts3
users3
websitecayenne.apache.org

People

Translate

site design / logo © 2022 Grokbase