Hi Please let me explain how I would do this in simple terms.
With Java EE Web, or with web applications in general, executions are request/response based. Doing it differently is not likely to succeed. Even when you create the illusion of server-initiated GUI updates, you use polling on the client. So the poll request is the natural candidate to update the GUI. Any long running thread must be totally decoupled from the GUI and must not even know anything about the polling request. The request must know about some identity kept inside the thread so some association can occur. After the long running thread is started, a polling request may call a method of a service that can collect the results that the thread may have produced asyncronously before. So the question remains where the long running thread resides. Just pick a standard method for this such as Java EE @Asynchronous or the message-driven bean. It is probably easiest to let @Asynchronous update a database table and let the poll request read the data. Otherwise this is going to be rather messy if you want to do this in a scalable way within a simple servlet container. You can check how others implemented this, e.g. http://stackoverflow.com/questions/1979277/solution-to-the-long-running-query-problem-in-a-web-application-asynchronous-re Regards, Bernard On Thu, 19 Sep 2013 15:41:46 +0200, you wrote: >>I consider writing an alternative implementation ... but I guess there is >>no better way? > >It will be the better solution. > >> I still do not get > >Still clinging :P > >> why it is a difference if Session adds a feedback message asynchronously to >> some third request thread compared to if some custom background thread does > >IIRC the problem was not any synchronization issue but unset threadLocals: >When messages are added to the session or to a component, the threadLocals are >set. When you do the same from your custom background thread the threadLocals >are not set. > >> keep a temporary reference to the session in a custom background thread > >Please don't do that: The reference to a session object is valid for the >duration of a single request only. > >Regards >Sven > > >On 09/19/2013 03:19 PM, Rafael W. wrote: >> I consider writing an alternative implementation where a thread-safe >> component works as a mediator for feedback messages such that the >> Wicket-thread can poll them from this thread-safe component. It's not the >> most beautiful solution since it generates quite some boilerplate which >> must in addition be explained to every developer, but I guess there is no >> better way? >> >> By the way, I am not clinging to my solution. I ask all this, because - at >> least for me - the Wicket source code is not always easy to follow. I just >> wanted to know the background for these decisions in order to find a better >> solutions since I was not aware of the exact reasons for the >> synchronization of the method. I read the code and obviously made some >> wrong assumptions over it which were corrected now. I would not know where >> I would get answers to these questions other than from this mailing list, >> this is why I am asking. >> >> PS: From your answer, I still do not get why it is a difference if Session >> adds a feedback message asynchronously to some third request thread >> compared to if some custom background thread does the same. Wouldn't this >> mean that I could simply keep a temporary reference to the session in a >> custom background thread and call Session.error instead? >>
