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
