This week's book giveaway is in the OCMJEA forum. We're giving away four copies of OCM Java EE 6 Enterprise Architect Exam Guide and have Paul Allen & Joseph Bambara on-line! See this thread for details.
Running within a JBoss 4x AS a MDB receives a message that is delegated for processing to other peer Session:Stateless EJB(s). According to the specification the participation of a Thread within a synch call through this environment will be unpredictable therefore, should not "Participate" in a transactional environment.
Is there an alternative to facilitate dare I say it
of a request through the JEE environment such, as above, that it would be
and managed accordingly, i.e. not having a negative impact or violate any contractual obligations imposed with in the container services provided by the implementer(in this case JBoss).....
I guess this will be more likely get proper attention in our EJB forum. Moving...
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Your question is a bit convoluted, perhaps due to its nature, anyway, let me rephrase it the way I understand it and you can tell me where I'm wrong (in the process we may just get a glimpse at the answer).
You have an MDB that receives a message and "delegates" (do you mean directly invokes?) a stateless session bean to process the message. Do you want to use threads within the stateless session bean (to, I assume, better facilitate the processing of the message)? And you worry about thread and transactional safety of this approach (and rightly so, especially since you have been warned by the spec). While I am pretty sure implementing this in a way that is completely safe could be paramount to reinventing the wheel (read: rewriting jboss), why not take a step back and see if you really need this parallel processing. Don't you have enough safe parallel processing already available? Why not split up the message bean, the messages themselves, simplify something elsewhere, thereby enabling yourself to leverage the parallel processing already implemented in accordance with the spec?
Thanks for the guidance on this topic, it kinda covered several technologies...
Good interpretation and response, by the way... It's always good to get a second opinion from a seasoned engineer, the reason why I posted it here in the first place.
In response to your reply, the only negative impact on this resolution you advised, would be to state the turnaround time of subsequent JMS messages to other message driven beans.
In breaking the work load down into parallel tasks and routing the calls to their destinations would, for an external synchronous call, have the need to block / wait until the other message driven beans have completed. Also in order to collate the response data and encapsulate it in a return Object message to the calling entity.
Basically have fine grained business logic encapsulated in worker message driven beans which will be invoked in an asynchronous fashion, to model parallel processing. The second stage would be to collate the data and return to the calling entity.
1 MDB acting as an internal hub to other dedicated worker MDB(s) in an async invocation.
Hope this helps / elaborates on the scenario...
Peter. [ March 06, 2006: Message edited by: Peter McLaughlin ]
Peter Mc Laughlin<br />SCJP | SCJD | SCEA Part(I).