Guys, This is quite a big message. Sorry for the trouble, but help much appreciated:
I have bunch of MDBs (all of them are different but listening to the same topic). As soon as they get a message, each one of them will invoke a session bean(One MDB to One Session Bean) and pass this message to them for processing.
The input message consists of Collection of items. The session bean will act on these items indivudually and produce decision candidates. So if the Collection has 100 items, the session beans produce 100 candidates. Each item has a unique reference, so all the 100 candidates from one session bean will be matched to 100 of second session bean.
That is, if I have a Session Bean A, it receives a message consisting of Collection of items(say 100 items). Each item has a reference that is unique. For our purpose, let the ref be integers from 1 to 100. Session bean will process these items one-by-one and produce exactly 100 decision candidates from 1 to 100.
Like wise, the same collection is sent to another session bean B(completely different from Session Bean A). It also produces 100 decision candidates. Similarly Session Bean C, D, E etc etc (there might be as many as 30 or 40 of them)
Now, at the other end, I need to collect the Decision Candidates "vertically", that is, I should collect Decision Candidate no.1 from Session Bean A, B etc etc for an item ref 1. Similarly for item ref 2, I've to collect candidates from A,B, C..etc. And so on. See the table below:
Bean Name Decision Candidates
Session Bean A - 1 2 3 4 5 6 7 ...100
Session Bean B - 1 2 3 4 5 6 7 ...100
Session Bean C - 1 2 3 4 5 6 7 ...100
Session Bean D - 1 2 3 4 5 6 7 ...100
The DCs are sent on the fly to a receiver which collects them one by one. It creates a bag for 1's, 2's etc. If it some how 'knows' that there were only four of the beans processing and it had received all 1's from four of them, then it can create a list and send them to another process.
My question is how can I collect decision candidate 1's , 2's, 3's ...etc from A, B, C,...etc if I don't know how may Beans are there processing? That is, when the beans processes are dynamic in nature(some beans may be added and some may be undeployed on the fly)how can I keep a count of them.
I designed a MDB as a receiver. When the MDBs are invoked at the first point, they send a notification about the process they are gonna invoke. When A,B,C etc are invoked, they send 100 messages each consisting of DCs to the same queue as MDBs send the notifications.
The constraint I imposed on this MDB Receiver is that under no circumstances, there shouldn't be more than one instance.
I know it is a lengthy question, but I would appreciate if any one rationalise this.
I will take a shot at it.
I think you need to use some kind of termination signal. In the MDB, you need to set a flag (perhaps in the database) indicating that a message collection is about to be processed. The operation is then delegated to the session bean.
When each session bean is done, it sends a "termination" message to a Termination MDB. The Termination MDB operates as follows:
1. If all of the termination messages for a given set have been received, the MDB does the final processing.
2. If not all of the termination messages have been receive, the Termination MDB records flips the flag for that termination message (again in the database).
That way, the Termination MDB sets flags for each termination message until all of them have been received, then performs your final processing.
In order for all of this to work, your initial MDB is going to need some mechanism for organizing incoming messages into groups. You could do this by timestamp, or using some kind of process id, depending on the nature of the problem you are solving.
Anyway, that is my 2-minute design sketch.
Hi Paul, I heartfully appreciate your suggestion. But I'm afraid that might not be suitable for the requirements. See the para below:
The Receiver should not wait for "all" the items (100 each) to be received before it process. That is, if it gets 1's from all four(supposing it know that there only four processes), it should bundle these 1's and send them for further processing. If it receives 2's, it should do the same. If by chance, it received only three of 3's, but one is missing (probably the fourth session bean might be takign considerably long time in acheiving the decision about the item), it should wait for some pre-configured before it does something with these 3's(Usually it sends them for further processing, but indicating that one 3 from session bean 4 is missing).
Due to this instant processing nature, probably there won't be any affect of termination messages (although, once the session bean finishes the processing, the control goes to MDB, which will then send a notification for unregistration. This just clears the list of processes receiver has its in memory).
I thought of JNDI Lookup, when an MDB startsup and asks the process to continue, it registers to JNDI. The only bottleneck it tha at the receiver MDB end, there'll be 100 times 4 = 400 times njdi lookup(there is a possibility that this collection may grown to thousands and thousands of items).
In my solution, I made the MDB receiver to first memorise the list of processes based on the notifications sent by the MDBs(before invoking the session beans to process). So before receiving first item by the receiver MDB, from the session bean, it would have the list of processes out there. (There could be a potential problem when I miss my registration notification(or late arrival), but start getting Decision candidates)
I would appreciate if any one has a similar situation or any pattern or suggestion or advise, please.
Thanks paul once again
The Receiver should not wait for "all" the items (100 each) to be received before it process. That is, if it gets 1's from all four(supposing it know that there only four processes), it should bundle these 1's and send them for further processing. If it receives 2's, it should do the same. If by chance, it received only three of 3's, but one is missing (probably the fourth session bean might be takign considerably long time in acheiving the decision about the item), it should wait for some pre-configured before it does something with these 3's (Usually it sends them for further processing, but indicating that one 3 from session bean 4 is missing).
This is a rather strange requirement. Let me see if I understand the reason for it. My guess is that you want to have a "timeout" period, after which processing will proceed even if some of the messages are not done processing yet.
If that is the case, I would still go with the termination messages, but incorporate some kind of Timer (initiated by the initial MDB) that wakes up and processes the received data even if there are some termination flags that have not been set. The Timer would also need to set another flag indicating that the work was complete, so that the Terminator MDB would know not to do anything more.
You can implement the Timer with an EJB 2.1 Timer bean or using the typical "thread hacks" that people use to implement timers in older EJB servers.