I think it isn't even an Wicket issue. I don't think the servlet spec guarantees the thread-safety of the http session ( http://stackoverflow.com/a/616723/176897). Even if it does, it will be between request threads. It would be very, very, unlikely that it would mandate that the session should work with random application-created threads.
In 2001, I've worked with IBM's Websphere Application Server, and if I remember correctly, it used to serialize the session to a database at the end of the request, and de-serialize it at the beginning of the next. It was a very poor implementation, but I don't think it is unreasonable to assume some servers still do something like this nowadays, especially if arranged in a cluster. In this kind of scenario, the session instance reference you keep and use in the background thread probably wouldn't work. I'm not saying it wouldn't work in a single Tomcat instance, it probably would. But it's not in the spec. Http sessions were made to be manipulated in a request context, and servers may assume this premise. On Thu, Sep 19, 2013 at 10:19 AM, Rafael W. <rafael....@web.de> 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? >
