Couldn't some sync() blocks around the higher scoped item solve that? Most
session-scoped things should be sync'd anyway.
-Pat
----- Original Message -----
From: "Jon Lipsky" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, September 24, 2003 4:45 AM
Subject: Re: [OS-webwork] Issue with component lifecycle dependencies
> Mike,
>
> Yeah, I was trying to make that point as well that scoped components and
IOC
> don't work well together. I realized after I sent the message that didn't
> state that anywhere. Thanks for putting it in clear english. :-)
>
> Cheers,
> Jon...
>
> ----- Original Message -----
> From: "Mike Cannon-Brookes" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Wednesday, September 24, 2003 12:03 PM
> Subject: Re: [OS-webwork] Issue with component lifecycle dependencies
>
>
> > Jon,
> >
> > Ahh yes - that's exactly the model we use too :)
> >
> > My point below was that mixing 'scoped components' together in an IOC
> > framework (specifically narrowing the scope) is a thread nightmare.
> >
> > This is exactly the reason you can't do it (xwork won't let you) and the
> > reason that a ThreadLocal + IoC approach is the way to go.
> >
> > Sorry if I wasn't clear.
> >
> > Cheers,
> > Mike
> >
> > On 24/9/03 5:46 PM, "Jon Lipsky" ([EMAIL PROTECTED]) penned
the
> > words:
> >
> > > Hi...
> > >
> > > I do this exact same thing with WebWork2 right now, however I use a
> > > ServletFilter and ThreadLocal variables to solve it.
> > >
> > > I have an app scoped component called PersistanceManager (PM)
> > >
> > > When a request comes in (A) it calls PM.getSession() and puts thes the
> > > session (SA) in the request and into a ThreadLocal variable.
> > >
> > > When a request comes in (B) it calls PM.getSession() and puts thes the
> > > session (SB) in the request and into a ThreadLocal variable.
> > >
> > > Similary, the request is finished the ServletFilter takes care of
> closing
> > > the session when the request is done.
> > >
> > > During the course of the request, the the code can just call methods
> like
> > >
> > > PM.create(theObject);
> > > PM.delete(theObject);
> > >
> > > What this really does is get this:
> > >
> > > public create(Object aObject)
> > > {
> > > // Get the session from the Thread Local variable
> > > Object vSession = threadLocalSession.get();
> > >
> > > create(vSession,aObject);
> > > }
> > >
> > > public create(Object aSession, Object aObject)
> > > {
> > > ... Insert create code here ...
> > > }
> > >
> > > What this gives me is the abilitiy to have fine control over the
session
> > > usage if I want, but for 99% of the time I can just assume the Session
> is
> > > already created in a ThreadLocal variable and happily go on my way. I
> can
> > > think of only 1 case that I have ever needed to open/close/manage the
> > > session manually once this version of the PersistanceManager and the
> > > ServletFilter were in place.
> > >
> > > Jon...
> > >
> > > BTW - I've used this pattern with Hibernate, JDBC and Prevayler with
out
> any
> > > problems. (That is the reason the Session object is typed as an
Object,
> > > because when I used this pattern with JDBC, then the session object is
> > > really a Connection object).
> > >
> > > ----- Original Message -----
> > > From: "Mike Cannon-Brookes" <[EMAIL PROTECTED]>
> > > To: <[EMAIL PROTECTED]>
> > > Sent: Wednesday, September 24, 2003 8:34 AM
> > > Subject: Re: [OS-webwork] Issue with component lifecycle dependencies
> > >
> > >
> > >> Uhm - please explain how it would be done? (could be done?)
> > >>
> > >> App scoped component : PersistenceManager (PM)
> > >>
> > >> There is therefore only one PM.
> > >>
> > >> Request scoped component: HibernateSession (HS)
> > >>
> > >> Two requests come in A and B, each with a request scoped component
(HS
> A
> > > and
> > >> HS B)
> > >>
> > >> A calls PM.setSession(HS A);
> > >> B calls PM.sesSession(HS B);
> > >> A calls PM.save();
> > >>
> > >> Now you're f'ked because request A is using HS B? :)
> > >>
> > >> This causes no end of pain as far as I can see. I'm not even sure how
> you
> > >> could possibly string them together?
> > >>
> > >> Mike
> > >>
> > >> On 24/9/03 2:24 PM, "Pat Lightbody" ([EMAIL PROTECTED]) penned the
> > > words:
> > >>
> > >>> I'd actually like to support this eventually (maybe 2.1). The reason
> for
> > >>> this is that most DB-based resources need to be request-scoped, but
> > > really
> > >>> only the DB (ie: Hibernate session) needs to. No reason why
everything
> > > else
> > >>> must get dragged down to that level as well. Since WebWork (read:
NOT
> > > XWork)
> > >>> can assume that a request scope can map directly to a single session
> > > scope,
> > >>> then this is totally possible (albeit hard).
> > >>>
> > >>> -Pat
> > >>>
> > >>> ----- Original Message -----
> > >>> From: "Jason Carreira" <[EMAIL PROTECTED]>
> > >>> To: <[EMAIL PROTECTED]>
> > >>> Sent: Tuesday, September 23, 2003 8:20 PM
> > >>> Subject: RE: [OS-webwork] Issue with component lifecycle
dependencies
> > >>>
> > >>>
> > >>> Umm... Because it's hard? :-)
> > >>>
> > >>> You'd have to have things stored in ThreadLocals and re-bound for
> every
> > >>> request, I think...
> > >>>
> > >>>> -----Original Message-----
> > >>>> From: Christian Meunier [mailto:[EMAIL PROTECTED]
> > >>>> Sent: Tuesday, September 23, 2003 11:14 PM
> > >>>> To: [EMAIL PROTECTED]
> > >>>> Subject: [OS-webwork] Issue with component lifecycle dependencies
> > >>>>
> > >>>>
> > >>>> Hi,
> > >>>>
> > >>>> looking at the doc i see "Note that while components are
> > >>>> allowed to have
> > >>>> dependencies on other components they must not depend on another
> > >>>> component that is of a narrower scope" , is there a good
> > >>>> reason why we
> > >>>> have this limitation, there are many good cases where an
application
> > >>>> scoped components could depend on a session scoped/request scoped
> > >>>> component and it does not look like it's supported at the moment.
> > >>>>
> > >>>> Regards
> > >>>> Christian Meunier
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>> -------------------------------------------------------
> > >>>> This sf.net email is sponsored by:ThinkGeek
> > >>>> Welcome to geek heaven.
> > >>>> http://thinkgeek.com/sf
> > >>>> _______________________________________________
> > >>>> Opensymphony-webwork mailing list
> > >>>> [EMAIL PROTECTED]
> > >>>> https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
> > >>>>
> > >>>
> > >>>
> > >>> -------------------------------------------------------
> > >>> This sf.net email is sponsored by:ThinkGeek
> > >>> Welcome to geek heaven.
> > >>> http://thinkgeek.com/sf
> > >>> _______________________________________________
> > >>> Opensymphony-webwork mailing list
> > >>> [EMAIL PROTECTED]
> > >>> https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
> > >>>
> > >>>
> > >>> -------------------------------------------------------
> > >>> This sf.net email is sponsored by:ThinkGeek
> > >>> Welcome to geek heaven.
> > >>> http://thinkgeek.com/sf
> > >>> _______________________________________________
> > >>> Opensymphony-webwork mailing list
> > >>> [EMAIL PROTECTED]
> > >>> https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
> > >>
> > >>
> > >>
> > >> -------------------------------------------------------
> > >> This sf.net email is sponsored by:ThinkGeek
> > >> Welcome to geek heaven.
> > >> http://thinkgeek.com/sf
> > >> _______________________________________________
> > >> Opensymphony-webwork mailing list
> > >> [EMAIL PROTECTED]
> > >> https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
> > >>
> > >
> > >
> > >
> > >
> > > -------------------------------------------------------
> > > This sf.net email is sponsored by:ThinkGeek
> > > Welcome to geek heaven.
> > > http://thinkgeek.com/sf
> > > _______________________________________________
> > > Opensymphony-webwork mailing list
> > > [EMAIL PROTECTED]
> > > https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
> >
> >
> >
> > -------------------------------------------------------
> > This sf.net email is sponsored by:ThinkGeek
> > Welcome to geek heaven.
> > http://thinkgeek.com/sf
> > _______________________________________________
> > Opensymphony-webwork mailing list
> > [EMAIL PROTECTED]
> > https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
> >
>
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Opensymphony-webwork mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
>
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
