We've used Spring Batch quite a bit to handle situations like this. Lots of good infrastructure that we didn't have to reinvent
Regards, Alex K On Thu, May 6, 2010 at 6:16 AM, Kristian Marinkovic < kristian.marinko...@porsche.co.at> wrote: > hi massimo, > > i had a similar problem a while back. > > i solved this problem by letting the long running thread > log its current state and failures into a db table (you could > also use a service and store it in memory). all the view > needs to know is the job id to query the correct state and > display it with an ajax updater. > > the downside is that it is not that simple anymore to cancel > the thread manually... but this was needed in my case. > > i guess you should always decouple the view from a long > running process anyways. especially in a web environment > that is stateless by nature. > > g, > kris > > > > Von: Massimo Lusetti <mluse...@gmail.com> > An: Tapestry users <users@tapestry.apache.org> > Datum: 06.05.2010 12:06 > Betreff: Heavy and long background process > > > > Hi all, > I need to process a big chunk on data uploaded from users. The whole > process takes up to 2-4 hours as involve a big change in the database. > > I've implemented this as a series of Invokable from ParallelExecutor > and a "controller" service which hold a weak references to the client > responsible for the data submitted. > > With a progresiveDisplay I keep the user informed of the progress of > the operation (and possibly of the errors involved), my reference is > kept in a cookie so users could still log out and come back later. > > Now the Futures from my Invokables are within a MAP keyed to my > cookie-key and stored in the Service implementation. > > May I ask if this solution sound reasonable to you? > > I already know this doesn't fit very well in a clustered environment > but it's not a problem right now... perhaps within 6-8 months. > > Thanks > -- > Massimo > http://meridio.blogspot.com > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > > >
