Re: propogating (or posting events of) object changes

From: Andrus Adamchik (andru..bjectstyle.org)
Date: Wed Jan 08 2003 - 16:32:36 EST

  • Next message: Craig Miskell: "Delete rules - back in"

    >
    > Any other ideas? The thing I like most about a shared SM is the memory
    > saving and unified cache management between DCs. Not sure if this leads to
    > more problems that it solves, though.

    I think it does. Like I said in another thread, my main concern is all this
    EOF mess of cross instance vs. local cache issues. It becomes really ugly
    when some of your users see the changes and others don't. I'd prefer the
    "all or nothing" strategy.

    So in Cayenne this was solved somewhat differently - no shared cache, each
    session (DataContext) has its own cache, so local and distributed behavior
    is consistent. I don't envision big memory problems, since cache is grabage
    collected with the session and is not accumulated. This is assuming that
    each session reads a limited number of rows (if not - app should use data
    rows or iterated queries in the first place).

    As I see it, the only serious drawback of Cayenne approach is less efficient
    cache reuse.

    Now, if we implement cache synchronization, this becomes a totally different
    story. Then there will be a benefit of making object store shared (I hope
    this will be easy). So to keep the flexibility and consistency we can do
    something like that:

    1. [distributed synchronization is on] ObjectStore is configured to belong
    to DataDomain and is shared by DataContexts

    2. [any cache synchronization is off] ObjectStore will be one per
    DataContext (current scenario) that provides consistency of local vs. remote
    DataContexts to the local updates.

    Andrus



    This archive was generated by hypermail 2.0.0 : Wed Jan 08 2003 - 16:32:41 EST