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 - dbquery
request.setAttribute(rs, rs)
requestDispatcher.include(jspFile)
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(jspFile);
rs - dbquery
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 - dbquery
request.setAttribute(rs, rs)
requestDispatcher.include(jspFile)
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
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(jspFile);
rs - dbquery
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 - dbquery
request.setAttribute(rs, rs)
requestDispatcher.include(jspFile)
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...
Managing resource life cycle during request
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
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
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
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
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...
