This week's giveaway is in the Android forum.
We're giving away four copies of Android Security Essentials Live Lessons and have Godfrey Nolan on-line!
See this thread for details.
The moose likes JSF and the fly likes Thread-pooled server as application-scoped bean. Producer-Consumer Problem? Help! Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Android Security Essentials Live Lessons this week in the Android forum!
JavaRanch » Java Forums » Java » JSF
Bookmark "Thread-pooled server as application-scoped bean. Producer-Consumer Problem? Help!" Watch "Thread-pooled server as application-scoped bean. Producer-Consumer Problem? Help!" New topic
Author

Thread-pooled server as application-scoped bean. Producer-Consumer Problem? Help!

Oliver Bodenhans
Greenhorn

Joined: Mar 08, 2011
Posts: 1
Hi everyone,

Since this is my first post here, let me begin by saying "hi" to everyone. I'm pretty new to JSF (actually, to Java and programming in general), so I'm having a bit of trouble with the following:

I'm trying to use a computational backend (Rserve, in case you're interested) in my Java EE application, which is supposed to handle request by clients (other beans). Information is gathered over the course
of several pages and the computation is started by pressing a commandButton on the final page. Now, it's obviously a bad idea to wait for the computations to finish before redirecting to the "results" page,
so I was thinking of generating a seperate thread for the computations, send the user back to the main page and alert him (email, popup,...) as soon as his results are processed.

I will also need a way to limit the number of concurrent computations to only a handful at a time, which probably means queueing up additional request and processing them successively.
Since all clients should be able to enqueue requests, my first impulse was to put the computation functionality into a application-scoped bean.

I've already looked at the Java Implementations of the Producer-Consumer Pattern, but I'm not sure if those are appropriate for an application scoped bean or JSF in general (while(true)-loops? meh?)...
Is there an established way of implementing this kind of thread-pooled server behaviour for JSF?

I hope that wasn't too confusing... if anyone knows how to approach this problem, I'd really appreciate if you could point me in the right direction.

Thank you so much,

Oli

Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 15958
    
  19

Welcome to the JavaRanch, Oliver!

Servlets and servlet-related stuff (like JSF backing beans) are forbidden by the J2Ee spec from spawning threads. That's because the threads that run the servlets come from a pool and if you start a new child thread and then return the parent to the pool, you have a warty thread in the thread pool.

For long-running processes, especially ones with a lot of contention, it's best to create an engine.

The engine is a component that possesses one or more work queues, processing functions, and maybe a thread pool of its own. servlet-level components (such as JSF action processors) can then post (synchronized) requests to the queue(s), query the engine for status, and obtain results from the engine.

Because the engine actually operates in one or more independent threads, you need a place to instantiate and run it outside the servlet environment. As it happens, these days, one of the best ways to do that is in an application context listener.


Customer surveys are for companies who didn't pay proper attention to begin with.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Thread-pooled server as application-scoped bean. Producer-Consumer Problem? Help!
 
Similar Threads
Producer/Consumer Design impacts exception handling
Problem with Consumer/Producer implementation
Who's using threads?
Session backing beans / STATE_SAVING_METHOD / WAS7
run and start together