Re: Thread Bound DataContexts - Bad Pattern?

From: Cris Daniluk (cris.danilu..mail.com)
Date: Mon Dec 05 2005 - 14:34:42 EST

  • Next message: Tore Halset: "Re: Thread Bound DataContexts - Bad Pattern?"

    Just to throw my two cents in.. I used to be afraid of the ThreadLocal
    stuff and only used it when absolutely necessary. I guess it just felt
    dirty... but, the more I've been working with Cayenne, the more
    extensively I've used it. The more I use it, the better my life (and
    code) gets.

    Any pattern that does not call that a Good Thing stinks.

    Cris

    On 12/5/05, Eric Schneider <eric.j.schneide..mail.com> wrote:
    > Joel,
    >
    > > 1) When do you ever need multiple datacontexts?
    >
    > I don't think you'd ever "need" to, but I've used a pattern with
    > multiple DataContexts. It's a little wacky, but worked pretty well.
    >
    > I basically have two DataContexts, a shared application scope
    > DataContext and another one in a tapestry visit object. The shared
    > DataContext contained reference objects like countries and states (or
    > objects that seem like extra baggage in a session scope DataContext).
    >
    > So, for example, in a user registration page, I'd use the shared
    > DataContext to build country and state popups. In the form's listener,
    > I'd capture the shared country and state selection and copy into the
    > user's visit DataContext, set relationship, and commit changes.
    >
    > I'm not sure how much more efficient this approach is, it's just
    > something I tried when noticing that the was a lot of mostly static
    > reference data being stored in the session's DataContext.
    >
    > Cheers,
    > e.
    >
    >
    > On 12/5/05, Joel Trunick <joel.trunic..ebifysolutions.com> wrote:
    > >
    > > I've been putting static methods on my domain objects to perform things
    > > like queries (for that object), and even simple methods load an instance
    > > by ID (returning an instance of the proper type). I find this
    > > organization very straightforward to use from a client perspective.
    > >
    > > However, to do this I rely on the DataContext bound to the thread a lot,
    > > and I'm wondering if this is architecturally flawed.
    > >
    > > I've already recognized that some (not all) of the queries belong on the
    > > client-side (tapestry pages), according to the DDD book, so I'm looking
    > > at getting rid of all these thread dependent methods.
    > >
    > > The question is then:
    > > 1) When do you ever need multiple datacontexts? (right now from web app)
    > > 2) Is the thread bound context a limitation?
    > >
    > > J
    > >
    > >
    >



    This archive was generated by hypermail 2.0.0 : Mon Dec 05 2005 - 14:34:44 EST