<PARANOIA> THIS IS FOR A CLIENT WHO HAS A JBG SUPPORT CONTRACT </PARANOIA>
Guys,
A team here needs a component that does something like this:
An invocation comes in, initiates a number of pieces of short-term, concurrent work. when all have been done, the result is aggregated and returned in the outbound invocation.
The component needs to be remotely invocable.
They are set on the idea of it being an SLSB.
I have said that I see no reason why they shouldn't just use a black box that transparently spawns, runs and joins a number of threads. If they want to call it from an SLSB, I don't see it doing any harm. There is a reluctance in the team to spawn threads inside a SLSB and they are putting forward a JMS based solution to avoid them personally having to spawn the threads. I think that this is using a hammer to crack a walnut.
The spec says :
" 25.1.2 Programming restrictions
The enterprise bean must not attempt to manage threads. The enterprise bean must not attempt to start, stop, suspend, or resume a thread; or to change a thread s priority or name. The enter-prise bean must not attempt to manage thread groups.
These functions are reserved for the EJB Container. Allowing the enterprise bean to manage threads would decrease the Container s ability to properly manage the runtime environment.
"
So my position is at odds with the letter of the spec.
I've suggested making the component a pluggable policy, so that if at a later date they want to move from a thread-based to a jms-based solution, it would not present a problem, but now we are arguing over what the initial impl should be.
I need an 'ex cathedra' pronouncement on this one.
If I have a black box that I call from a Session Bean, is it my concern whether it spawns threads to do it's work, provided that they do not have any side effect on my bean ?
Jules
------------------------------------------------------- This SF.net email is sponsored by: ObjectStore. If flattening out C++ or Java code to make your application fit in a relational database is painful, don't do it! Check out ObjectStore. Now part of Progress Software. http://www.objectstore.net/sourceforge _______________________________________________ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
