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
