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
