I think you are right, both a specified DC as well as a presumed DC
(threadlocal) is probably both required to cover all cases.
It sounds like multiple DC's are used for performance (which actually
sounds dubious in my mind), but I think they are also used for more than
one database? I guess if you have a production and archive database you
can move objects between datacontexts and thus db's?
Joel
-----Original Message-----
From: Philip Miller [mailto:philip.mille..bc.co.uk]
Sent: Monday, December 05, 2005 11:38 AM
To: cayenne-use..bjectstyle.org
Subject: RE: Thread Bound DataContexts - Bad Pattern?
Either way I don't see how it's a problem for your static methods, Joel.
My business objects are stacked with methods which look like this:
public static Foo giveMeANewFooInContext(DataContext context);
> -----Original Message-----
> From: Joshua Pyle [mailto:joshua.t.pyl..mail.com]
> Sent: 05 December 2005 17:29
> To: cayenne-use..bjectstyle.org
> Subject: Re: Thread Bound DataContexts - Bad Pattern?
>
> I'm heavily using threadbound data contexts in my web apps.
> Its working great. I so need to ever have more than one
> datacontext. If I need multiple mappings pointing to
> different databases I just set it up in the current context.
> My DAO api is now clean in that the DataContext is not passed
> into methods and this in effect makes my DAO API interface
> unaware of cayenne.
>
> I have found one limitation, the datacontext only lives
> during the lifetime of the request and as such any chaching
> benefits only exist during the processing of the request.
>
> --
> Joshua T. Pyle
> Go has always existed.
>
>
> 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 e-mail (and any attachments) is confidential and may contain
personal views which are not the views of the BBC unless specifically
stated.
If you have received it in error, please delete it from your system.
Do not use, copy or disclose the information in any way nor act in
reliance on it and notify the sender immediately. Please note that the
BBC monitors e-mails sent or received.
Further communication will signify your consent to this.
This archive was generated by hypermail 2.0.0 : Mon Dec 05 2005 - 18:49:11 EST