struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Charles Godfrey <cha...@gmail.com>
Subject Re: Struts2 Memory Management
Date Wed, 19 Oct 2011 16:12:14 GMT
Thanks for all the great feedback guys.

Right now its a custom framework (similar to Struts) but uses straight JDBC
and no JSP, ie. presentation is done in Java classes using only
out.println(). It performs very well. Customers who use the product can have
100 rows or 10,000 rows in a table, and several have into the 1000's.

The lazy load comment earlier is a good one that I wished I thought of on
the spot. It will solve the issue of large number of rows. I'l revisit that
with the team.

The impetus for this was me trying to move into an MVC design (i.e. no more
out.println() in the action classes) and chose Struts as the framework since
what we have closely resembles it and several devs including myself have
used it successfully in the past.

Thanks a lot guys,
-Charles



On Wed, Oct 19, 2011 at 11:50 AM, Eric Lentz <Eric.Lentz@sherwin.com> wrote:

> > any current framework can easily handle such a request
>
> I agree. Maybe it would be helpful for the OP to let us in on what other
> framework is being considered by way of comparison so the OP can tap into
> the wealth of knowledge on this forum for real arguments to take back to
> the opposition. Also, is this 1000 objects a real use case or a
> red-herring that someone in a meeting threw out because they had some kind
> of bend away from Struts (OP's statement: "assume the above is a
> requirement for now")? I'd suggest focusing on real use cases if this 1000
> example isn't one.
>
> Like Eric points out, depending on the size of the objects, 1000 isn't
> really that much anyway. How are records being read from the DB? For
> example, using Hibernate? If so, you may want to check on your
> PersistenceContext and see how many objects are being stored there (and
> GC'd and possibly dirty checked when the session closes).

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message