I'm having the same problem, we're you able to solve this? I have a conversation scoped pojo, which calls an asynchronous method. I would need some solution (or compromise) to display the results of this asynchronous method in the conversation.
The Problem is:
The asynchronous method is processed in a completely new event context and does not have access to the session or conversation context state of the caller.
So what I did when I was working on this, was to create an application-scoped bean that acts as a data-store. I passed a reference to the bean and a unique id to the asynchronous method, when it finishes its work, the result gets written to the bean. Per Ajax, I then polled a method on the application scoped bean that would check if the result for the given id was done, and would serve it if available.
We had a similar problem just the other day and solved it by starting our own threads from a bean (not recomended - and even not allowed by J2EE specs I belive - but couldn't realy find a clean explanation on why)
Hope that helps.
MANY THANKS Christian,
this was very helpful!
I now have a conversation scoped stateful EJB session bean which calls an asynchronous method on another (autocreated) component. This asynchronous method does the background process, while the user can continue browsing the page, still in the long-running conversation. Once the background process is complete, its results will be put in an application scoped
data-storecomponent like you described, hereafter called
result holder, using a map, where the key is the conversationId which was passed earlier to the asynchronous method by the calling conversation component. After storing the results, the asynchronous method raises an asynchoronous event. The observer of this event (also in the result holder) fires an pushEventLister event. The results are then pushed to the view, to avoid any page reload. The conversation can find the results belonging to it from the result holder by using the conversationId and clean up the map entry after it's no longer needed.
Seems to work alright, but a thing that worries me is the scalability of this solution (the application scoped component and the manual clean up it requires).
Click HELP for text formatting instructions. Then edit this text and check the preview.
Yeah guys, I've been doing this same thing for some time now. I had started down the path of creating my own thread that did the background JMX calls. The thread ran in an application scoped bean but then I realized that creating your own threads violates container management and that explains why no Seam services were available in this separate thread. Basically, @Asynchronous does this but Seam knows that it did it and manages the thread.
Am converting my code to use @Asynchronous (which works well) - but yes, the explanation about this thread running in a different context is still a roadblock - and I'm deciding the only way to SAVE my data after the JMX background process is to put it into the same application scoped bean (i'll use uniqueIDs like you guys have done - good idea). But all this is pretty nasty for a longterm scalable solution (at least I think). I think we could also make use of a Seam Cache and put stuff in there (there is a Seam Cache chapter after the Asynchrous chapter - chapter 23 I believe).
Mainly, I'm glad that I am doing something that you guys have also done and been playing with - that gives a little assurance :)