RE: application scope for a datacontext ?

From: Cris Daniluk (cris.danilu..laraview.com)
Date: Fri Mar 04 2005 - 10:40:29 EST

  • Next message: Cris Daniluk: "RE: Oracle XMLType ?"

    Just a couple of thoughts that occur to me, without any knowledge whatsoever
    of the details of your system...

    > I am currently developing a web application using Cayenne that makes
    > read-only accesses to a database, with a Level 1 caching (no
    > cache sharing).
    > I am thinking about a way to have only one DataContext
    > serving only one
    > ObjectStore so every user would then benefit from everybody's past
    > requests.
    >
    The context is not entirely thread safe, but more importantly, even if it
    were, by sharing it across all threads, you create a major contention point.
    Since the context would have to synchronize quite a bit, you're making
    conditions ripe for a massive bottleneck, totally eliminating any gain from
    a centralized cache.

    > Is it possible and a good idea to change a Session-Bound
    > DataContext to
    > an Application-Bound DataContext or should I stick to session-bound
    > datacontexts ?
    > If yes, how can I do it and is it thread-safe? How to prevent
    > the cache
    > from growing infinitely?
    >
    My initial thought is that you want to use a JVM-shared cache for your
    objects, but still retain the session-scoped DataContext.

    > Also, our database will also be frequently updated by other
    > applications... How can the datacontext be aware of those changes?
    >
    A tricky matter. Cayenne supports remote update notifications (at least in
    1.2) via multicast and a few other mechanisms. It's really designed for
    having distributed Cayennes talk to each other, but you certainly could tap
    the protocol to do it yourself I'm sure. Andrus?

    Otherwise, we've traditionally embedded a notification system into our
    application. You could have a servlet that is triggered by a local IP to
    reset the cache of various objects - this is inelegant but quick and
    effective. You could also communicate more fine-grained changes via JMS. The
    level of elegance and effort required is truly a function of your specific
    application. There are a million ways to do it, and every one of them has at
    least one environment where it's the right idea.

    > Thanks in advance...
    >
    Good luck,

    Cris



    This archive was generated by hypermail 2.0.0 : Fri Mar 04 2005 - 10:40:20 EST