> -----Original Message-----
> From: Joe Germuska [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, March 22, 2005 6:10 AM
> To: Bruce Woods; dev@struts.apache.org
> Subject: Re: Infrastructure for concurrent processing within Struts
> Action classes
>
>
> At 4:14 PM -0800 3/21/05, Bruce Woods wrote:
> > I am currently developing an application that is report
> intensive..
> >The screens will require several "report" queries to the database
> >and I would like to be able to run the queries in parallel, as part
> >of my struts Action..
> > The development team I am working with is in the process of
> >transitioning our home-grown MVC framework to struts. Unfortunately,
> >this is one piece that our existing MVC supported that is lacking in
> >struts. This "parallelism" was integrated into the command
> >processing infrastructure (which is very similar to the Command
> >Chaining being added in Struts 1.3).
> > Any idea if any future struts infrastructure has been
> designed that
> >may support this type of parallelism ?
>
> I don't think anyone has ever identified this as a use case which
> Struts could or should support. I don't immediately see how you make
> the connection between the ComposableRequestProcessor and any kind of
> parallel processing, but then I think your entire design approach is
> kind of new to me.
>
> Ideally, the ComposableRequestProcessor makes it plausible for you to
> add something like this parallel processing by modifying the request
> processing chain, whether or not Struts adds specific infrastructure
> for that into its core.
>
> If you want to describe in more detail the use cases and how you
> implemented a solution in your existing framework, we could probably
> figure out an analogous way to achieve it in Struts.
>
> Joe
>
> --
> Joe Germuska
> [EMAIL PROTECTED]
> http://blog.germuska.com
> "Narrow minds are weapons made for mass destruction" -The Ex
>
Originally, our framework implemented command chaining very similar to what is
being done for struts 1.3. When the response time of some of our report screens
was too slow, we decided to integrate this capability into the framework so it
would be easy to execute command in parallel. Basically, any potentially
long-running command where the processing is independent of other commands used
to render a page is a good candidate.
Below is a sample "event" from our framework (analygous to the struts Action) :
<event uri="viewReport" action="dashboard">
<command class="com.xxx.command.report.CheckReportsAvailableStatus"/>
<command class="com.xxx.command.report.DashboardSortColumnCommand"/>
<command class="com.xxx.command.report.LoadReportDates"/>
<threadedCommandGroup>
<command class="com.xxx.command.report.GetMinBooksClosedTime"/>
<command class="com.xxx.command.report.LoadReport1">
<map source="campaignSummaryInfo"
target="@{localAttr.rptPayloadName}"/>
</command>
<command class="com.xxx.command.report.LoadReport2">
<map source="convFunnelSummaryInfo"
target="@{localAttr.rptPayloadName}"/>
</command>
<command class="com.xxx.command.report.LoadReport3">
<map source="executiveSummaryInfo"
target="@{localAttr.rptPayloadName}"/>
</command>
<command class="com.xxx.command.report.LoadReport4">
<map source="executiveActiveOfferInfo"
target="@{localAttr.rptPayloadName}"/>
</command>
<command class="com.xxx.command.report.LoadReport5">
<map source="listingCountInfo"
target="@{localAttr.rptPayloadName}"/>
<map source="dashboard-listing-count"
target="@{localAttr.reportName}"/>
</command>
</threadedCommandGroup>
<successView uri="/WEB-INF/jsp/report/dashboard.jsp"/>
<errorView uri="/WEB-INF/jsp/report/report_error.jsp"/>
</event>
You will notice a number of <Command..>s, followed by the
<threadedCommandGroup>. Basically, each of the <Command> classes implement a
very simple interface (public boolean validate(...) and public int
execute(...)). Our Dispatcher executes each command sequentially, until it
encounters the <threadedCommandGroup>. At this point, all commands within the
group are executed in parallel. The Dispatcher waits until all commands in the
group have completed, the continues on with the chain.
The nice thing about the above design is that no additional coding required to
run the commands in parallel. Of course we use this judiciuosly in our app due
to the overhead of maintaining the additional threads..
-Bruce
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
