Re: Managing resource life cycle during request
>I'm not suggesting that coding this way is wrong. I would suggest that this
>isn't optimal model/view separation, which is one of the main motives for
>using Struts, right?
What really is true model/view separation. In the 15 years or so that I've
been coding, I find this to be more of an academic pursuit. The alternative
is to make it a collection which, imho, is not cleaner since it has its own
downsides.
My $0.02,
- jeff
- Original Message -
From: "Cook, Levi" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, June 05, 2001 4:20 PM
Subject: RE: Managing resource life cycle during request
> Just a few notes:
>
> 1. Struts doesn't dissallow the operations you outline below. If you are
> using Struts, and you really need to do this, you can make the same calls
> from your Action implementation.
>
> public class SomeAction extends Action {
> public ActionForward perform(ActionMapping mapping, ActionForm form,
> HttpServletRequest request, HttpServletResponse response)
>throws IOException, ServletException {
> ServletContext context = servlet.getServletContext();
> RequestDispatcher dispatcher =
context.getRequestDispatcher();
>
> rs <-
> request.setAttribute("rs", rs);
> dispatcher.include(request, response);
> rs.close();
>
> // ActionServlet doesn't do any more response processing..
> return null;
> }
> }
>
> I'm not suggesting that coding this way is wrong. I would suggest that
this
> isn't optimal model/view separation, which is one of the main motives for
> using Struts, right?
>
> 2. My use of the term "acquiring" may have been wrong, or at least
> ambiguous. More accurately, I would suggest that view components should
not
> have knowledge of, or responsibility for non-memory, finite resources.
>
> 3. You must rely on Garbage collection in Java, you may not like its
> behaviors, but its all you get. Also, I would never suggest that you rely
on
> garbage collection to free, non-memory resources, like db-handles.
>
> -- Levi
>
>
>
> -Original Message-
> From: Jeff Trent [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, June 05, 2001 2:05 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Managing resource life cycle during request
>
>
> Levi,
>
> The view/JSP does not acquire the resource. Here is a sample of how the
> code use to work pre-struts:
> Servlet.doGet()
> {
> ...
> rs <-
> request.setAttribute("rs", rs)
>
> requestDispatcher.include()
>
> rs.close();
> }
>
> In JSP:
> ...
> rs = request.getAttribute("rs")
> while (rs.next())
> {
> ...
> }
>
> - - -
>
> The problem is that there is no appropriate counterpart in the world of
> struts. Sure, I can copy the row data to a collection and then walk the
> collection. But for various reasons, this may be inappropriate
(especially
> for large result sets represented by a cursor).
>
> Finally, you should not depend on garbage collection. The garbage
collector
> is not always called and its certainly not called as often as you would
want
> it to when you need to free scarce resources like db handles.
>
> - jeff
>
>
> - Original Message -
> From: "Cook, Levi" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Tuesday, June 05, 2001 1:40 PM
> Subject: RE: Managing resource life cycle during request
>
>
> > Can you elaborate on your resource cleanup requirements?
> >
> > My view on designing a responsible object is that I must make sure it
> > eventually releases any, non-memory, finite resources it uses. This
design
> > strategy, coupled with garbage collection ensures my system doesn't run
> out
> > of those resources (eg. file handles, sockets, etc.).
> >
> > Given that ActionForms and JSPs should play the "view" role in Struts, I
> > would question a design that has them acquiring non-memory resources.
But,
> > alas, I don't know your system or situation..
> >
> > Regards,
> > Levi Cook
> >
> >
> > -Original Message-
> > From: Ted Husted [mailto:[EMAIL PROTECTED]]
> > Sent: Monday, June 04, 2001 10:31 PM
> > To: [EMAIL PROTECTED]
> > Subject: Re: Managing resource life cycle during request
> >
> >
> > I doubt that overriding ActionServlet.process() would work. The
> > controller sends back the response, and it's done. It's then up to HTTP
> > to deliver the view, usually a JSP.
> >
> > Any clean-up routine would have to be the responsibility of the view,
> > which puts you into the scriplet zone.
> >
> > Jeff Trent wrote:
> > >
> > > Well, it looks to me that short of overriding ActionServlet.process(),
> > there
> > > is no way one can clean-up resources after the page has been
rendered...
> >
RE: Managing resource life cycle during request
Just a few notes:
1. Struts doesn't dissallow the operations you outline below. If you are
using Struts, and you really need to do this, you can make the same calls
from your Action implementation.
public class SomeAction extends Action {
public ActionForward perform(ActionMapping mapping, ActionForm form,
HttpServletRequest request, HttpServletResponse response)
throws IOException, ServletException {
ServletContext context = servlet.getServletContext();
RequestDispatcher dispatcher = context.getRequestDispatcher();
rs <-
request.setAttribute("rs", rs);
dispatcher.include(request, response);
rs.close();
// ActionServlet doesn't do any more response processing..
return null;
}
}
I'm not suggesting that coding this way is wrong. I would suggest that this
isn't optimal model/view separation, which is one of the main motives for
using Struts, right?
2. My use of the term "acquiring" may have been wrong, or at least
ambiguous. More accurately, I would suggest that view components should not
have knowledge of, or responsibility for non-memory, finite resources.
3. You must rely on Garbage collection in Java, you may not like its
behaviors, but its all you get. Also, I would never suggest that you rely on
garbage collection to free, non-memory resources, like db-handles.
-- Levi
-Original Message-
From: Jeff Trent [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, June 05, 2001 2:05 PM
To: [EMAIL PROTECTED]
Subject: Re: Managing resource life cycle during request
Levi,
The view/JSP does not acquire the resource. Here is a sample of how the
code use to work pre-struts:
Servlet.doGet()
{
...
rs <-
request.setAttribute("rs", rs)
requestDispatcher.include()
rs.close();
}
In JSP:
...
rs = request.getAttribute("rs")
while (rs.next())
{
...
}
- - -
The problem is that there is no appropriate counterpart in the world of
struts. Sure, I can copy the row data to a collection and then walk the
collection. But for various reasons, this may be inappropriate (especially
for large result sets represented by a cursor).
Finally, you should not depend on garbage collection. The garbage collector
is not always called and its certainly not called as often as you would want
it to when you need to free scarce resources like db handles.
- jeff
- Original Message -
From: "Cook, Levi" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, June 05, 2001 1:40 PM
Subject: RE: Managing resource life cycle during request
> Can you elaborate on your resource cleanup requirements?
>
> My view on designing a responsible object is that I must make sure it
> eventually releases any, non-memory, finite resources it uses. This design
> strategy, coupled with garbage collection ensures my system doesn't run
out
> of those resources (eg. file handles, sockets, etc.).
>
> Given that ActionForms and JSPs should play the "view" role in Struts, I
> would question a design that has them acquiring non-memory resources. But,
> alas, I don't know your system or situation..
>
> Regards,
> Levi Cook
>
>
> -----Original Message-----
> From: Ted Husted [mailto:[EMAIL PROTECTED]]
> Sent: Monday, June 04, 2001 10:31 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Managing resource life cycle during request
>
>
> I doubt that overriding ActionServlet.process() would work. The
> controller sends back the response, and it's done. It's then up to HTTP
> to deliver the view, usually a JSP.
>
> Any clean-up routine would have to be the responsibility of the view,
> which puts you into the scriplet zone.
>
> Jeff Trent wrote:
> >
> > Well, it looks to me that short of overriding ActionServlet.process(),
> there
> > is no way one can clean-up resources after the page has been rendered...
>
Re: Managing resource life cycle during request
Levi,
The view/JSP does not acquire the resource. Here is a sample of how the
code use to work pre-struts:
Servlet.doGet()
{
...
rs <-
request.setAttribute("rs", rs)
requestDispatcher.include()
rs.close();
}
In JSP:
...
rs = request.getAttribute("rs")
while (rs.next())
{
...
}
- - -
The problem is that there is no appropriate counterpart in the world of
struts. Sure, I can copy the row data to a collection and then walk the
collection. But for various reasons, this may be inappropriate (especially
for large result sets represented by a cursor).
Finally, you should not depend on garbage collection. The garbage collector
is not always called and its certainly not called as often as you would want
it to when you need to free scarce resources like db handles.
- jeff
- Original Message -
From: "Cook, Levi" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, June 05, 2001 1:40 PM
Subject: RE: Managing resource life cycle during request
> Can you elaborate on your resource cleanup requirements?
>
> My view on designing a responsible object is that I must make sure it
> eventually releases any, non-memory, finite resources it uses. This design
> strategy, coupled with garbage collection ensures my system doesn't run
out
> of those resources (eg. file handles, sockets, etc.).
>
> Given that ActionForms and JSPs should play the "view" role in Struts, I
> would question a design that has them acquiring non-memory resources. But,
> alas, I don't know your system or situation..
>
> Regards,
> Levi Cook
>
>
> -Original Message-
> From: Ted Husted [mailto:[EMAIL PROTECTED]]
> Sent: Monday, June 04, 2001 10:31 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Managing resource life cycle during request
>
>
> I doubt that overriding ActionServlet.process() would work. The
> controller sends back the response, and it's done. It's then up to HTTP
> to deliver the view, usually a JSP.
>
> Any clean-up routine would have to be the responsibility of the view,
> which puts you into the scriplet zone.
>
> Jeff Trent wrote:
> >
> > Well, it looks to me that short of overriding ActionServlet.process(),
> there
> > is no way one can clean-up resources after the page has been rendered...
>
RE: Managing resource life cycle during request
Can you elaborate on your resource cleanup requirements? My view on designing a responsible object is that I must make sure it eventually releases any, non-memory, finite resources it uses. This design strategy, coupled with garbage collection ensures my system doesn't run out of those resources (eg. file handles, sockets, etc.). Given that ActionForms and JSPs should play the "view" role in Struts, I would question a design that has them acquiring non-memory resources. But, alas, I don't know your system or situation.. Regards, Levi Cook -Original Message- From: Ted Husted [mailto:[EMAIL PROTECTED]] Sent: Monday, June 04, 2001 10:31 PM To: [EMAIL PROTECTED] Subject: Re: Managing resource life cycle during request I doubt that overriding ActionServlet.process() would work. The controller sends back the response, and it's done. It's then up to HTTP to deliver the view, usually a JSP. Any clean-up routine would have to be the responsibility of the view, which puts you into the scriplet zone. Jeff Trent wrote: > > Well, it looks to me that short of overriding ActionServlet.process(), there > is no way one can clean-up resources after the page has been rendered...
Re: Managing resource life cycle during request
I doubt that overriding ActionServlet.process() would work. The controller sends back the response, and it's done. It's then up to HTTP to deliver the view, usually a JSP. Any clean-up routine would have to be the responsibility of the view, which puts you into the scriplet zone. Jeff Trent wrote: > > Well, it looks to me that short of overriding ActionServlet.process(), there > is no way one can clean-up resources after the page has been rendered...
Re: Managing resource life cycle during request
Well, it looks to me that short of overriding ActionServlet.process(), there is no way one can clean-up resources after the page has been rendered... - Original Message - From: "Jeff Trent" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, June 04, 2001 10:54 PM Subject: Re: Managing resource life cycle during request > That's sounds okay for simple forms, but I'd rather not serialize objects > from a multi-row recordset to a collection every time. Too much overhead! > Let me put the question another way, in Struts, what method on the form or > action class gets called following the rendering of the input page? I'll > check source code now for this answer... > > - jeff > > - Original Message - > From: "Ted Husted" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Monday, June 04, 2001 9:25 PM > Subject: Re: Managing resource life cycle during request > > > > The types of objects I use for presentation should be disposed and > > garbage collected. Here we would be talking about standard collections > > of mainly Strings and maybe a few primitive types. Anything kinky would > > be handled in the action. The view gets everything handed to it on a > > silver platter. > > > > Jeff Trent wrote: > > > > > > Ted, > > > > > > Just because the objects are held in the bean doesn't necessary mean > they > > > will automatically be cleaned-up. Am I missing something here? I also > > > agree, I don't want to be writing queries within the JSP. > > > > > > Thanks, > > > - jeff > > > >
Re: Managing resource life cycle during request
Following the rendering? By Struts? None. It's a straight JSP (or other view technology, like a Velocity template). Generally, things go into the request, and are disposed when the request is disposed. There's an enhancement to the iterate tag in the works that uses a RowSet directly. < http://www.mail-archive.com/struts-user@jakarta.apache.org/msg07910.html > Jeff Trent wrote: > > That's sounds okay for simple forms, but I'd rather not serialize objects > from a multi-row recordset to a collection every time. Too much overhead! > Let me put the question another way, in Struts, what method on the form or > action class gets called following the rendering of the input page? I'll > check source code now for this answer... > > - jeff
Re: Managing resource life cycle during request
That's sounds okay for simple forms, but I'd rather not serialize objects from a multi-row recordset to a collection every time. Too much overhead! Let me put the question another way, in Struts, what method on the form or action class gets called following the rendering of the input page? I'll check source code now for this answer... - jeff - Original Message - From: "Ted Husted" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, June 04, 2001 9:25 PM Subject: Re: Managing resource life cycle during request > The types of objects I use for presentation should be disposed and > garbage collected. Here we would be talking about standard collections > of mainly Strings and maybe a few primitive types. Anything kinky would > be handled in the action. The view gets everything handed to it on a > silver platter. > > Jeff Trent wrote: > > > > Ted, > > > > Just because the objects are held in the bean doesn't necessary mean they > > will automatically be cleaned-up. Am I missing something here? I also > > agree, I don't want to be writing queries within the JSP. > > > > Thanks, > > - jeff >
Re: Managing resource life cycle during request
The types of objects I use for presentation should be disposed and garbage collected. Here we would be talking about standard collections of mainly Strings and maybe a few primitive types. Anything kinky would be handled in the action. The view gets everything handed to it on a silver platter. Jeff Trent wrote: > > Ted, > > Just because the objects are held in the bean doesn't necessary mean they > will automatically be cleaned-up. Am I missing something here? I also > agree, I don't want to be writing queries within the JSP. > > Thanks, > - jeff
Re: Managing resource life cycle during request
Ted, Just because the objects are held in the bean doesn't necessary mean they will automatically be cleaned-up. Am I missing something here? I also agree, I don't want to be writing queries within the JSP. Thanks, - jeff - Original Message - From: "Ted Husted" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, June 04, 2001 6:13 PM Subject: Re: Managing resource life cycle during request > In general, you should put everything you need for the presentation into > a JavaBean, release any other resources, and return just the bean in the > request. This way you also do things like immediately return the > connection to the pool (before anything bad happens). > > As and for an alternative, the Jakarta JDBC tags work great with Struts > too, if you like doing things on the page. > > Personally, I use mostly RowSets, which can be disconnected from the > data source as soon as the command completes. The Struts tags don't > support RowSets directly (yet) so I end up pounding the RowSet into a > value object bean and/or an ArrayList for iterate (though a fix for that > is in the works too). > > For more, see Part 2 of Strut by Strut under "Coming Soon" at < > http://www.husted.com/about/struts/ > > > -- Ted Husted, Husted dot Com, Fairport NY USA. > -- Custom Software ~ Technical Services. > -- Tel 716 737-3463. > -- http://www.husted.com/about/struts/ > > > > Jeff Trent wrote: > > > > I was wondering how other people deal with physical resource objects > > (eg. db result sets, etc.) during a request. Before struts, I use to > > allocate the resource, call request.setAttribute() with the resource > > object, call request dispatcher (to do jsp presentation), then clean > > up the resource back in the servlet upon return. In struts, this has > > all been abstracted out. Is there an alternative way to manage > > request-scoped resources like this under struts? > > > > thanks, > > jeff > > >
Re: Managing resource life cycle during request
In general, you should put everything you need for the presentation into a JavaBean, release any other resources, and return just the bean in the request. This way you also do things like immediately return the connection to the pool (before anything bad happens). As and for an alternative, the Jakarta JDBC tags work great with Struts too, if you like doing things on the page. Personally, I use mostly RowSets, which can be disconnected from the data source as soon as the command completes. The Struts tags don't support RowSets directly (yet) so I end up pounding the RowSet into a value object bean and/or an ArrayList for iterate (though a fix for that is in the works too). For more, see Part 2 of Strut by Strut under "Coming Soon" at < http://www.husted.com/about/struts/ > -- Ted Husted, Husted dot Com, Fairport NY USA. -- Custom Software ~ Technical Services. -- Tel 716 737-3463. -- http://www.husted.com/about/struts/ > Jeff Trent wrote: > > I was wondering how other people deal with physical resource objects > (eg. db result sets, etc.) during a request. Before struts, I use to > allocate the resource, call request.setAttribute() with the resource > object, call request dispatcher (to do jsp presentation), then clean > up the resource back in the servlet upon return. In struts, this has > all been abstracted out. Is there an alternative way to manage > request-scoped resources like this under struts? > > thanks, > jeff >
