I am new to J2EE, I just want a quick idea of what is possible and where to
start looking.
My app combines a remote UI and some fairly heavy duty file processing. I
don't want to do the processing in the main thread of the session bean that
the UI is talking to, because that would kill it for a while.
In a traditional environment (eg an MFC app) I would use a separate thread
to do the processing. What is the J2EE way to do this?
I thought of using a message driven bean to do the processing. The session
bean can send it a message to do the processing, and maybe then poll for
completion. Is that a typical way of doing it? Does the message driven bean
always get a separate thread, and how can this be controlled?
EricF - 07 Jan 2005 05:22 GMT
>I am new to J2EE, I just want a quick idea of what is possible and where to
>start looking.
[quoted text clipped - 10 lines]
>completion. Is that a typical way of doing it? Does the message driven bean
>always get a separate thread, and how can this be controlled?
You might want to get a better understanding of EJB and some of the
restrictions and best practices.
Take a look here:
http://www.theserverside.com/discussions/thread.tss?thread_id=28980
The container handles threading for you and session beans should not be doing
threading.
Session beans scale well because the container can have multiple instances of
a session bean. So in general, a session bean should not need to start a
thread.
One needs to be very careful if a bean is doing any writing to a file:
http://weblogs.java.net/blog/simongbrown/archive/2003/10/file_access_in.html
Offloading processing to a MDB can be quite useful - but polling would negate
delegating any work - and I'm not sure how one would do that polling unless
the MDB write to a database.
It doesn't sound like EJB may be the best solution to your problem - but
without knowing more, they might be perfect with a different design.
My 2 cents ...
Eric