MDB/JMS 'And' logic
Hello,
First off, let me start with the standard 'not sure if this is in the correct forum' statement.
Working with MDBs and have JBoss configured to allow five instances of a MDB. For this discussion, let's say that there are three MDBs, all tied to their respective JMS queues (JMS is storing messages in MySQL DB):
A
B
C
MDB A will forward five work requests to MDB B, MDB B will process them and then forward to MDB C. MDB C is essentially a filter to ensure that all five requests are complete, and the perhaps forwarding to another mdb, sending an email, whatever (i.e. completion task).
Now, here's my problem... it's possible for MDB B to receive it's five work requests (from MDB A) at the same time, complete them at the same time and forward to MDB C at the same time, so is it possible for MDB C to effectively check if all requests are complete? (i.e. if req1 && req2... && req5)
Somehow now it seems to work if MDB C queries the objects via persistence, that MDB B worked on... i.e. check req[n] status from DB. It appears that the first four requests drop off and then the fifth one processes, but I want to understand why.
If the five instances are running at the same, how can any of the MDB C 'checks' pass? For my thinking, they should all pass, as all MDB B work requests are complete, or they would all fail. Unless somehow one lags behind just enough to be 'last' which causes the first four checks to fail but allows the 'last' check to pass, I'm a little confused as to how only one check can pass.
Also, there is a requests group object which all work requests pertain to, i.e. requestManager is the parent to work request[n]. Currently, MBD C will check if all work requests, five in this example, are complete and update the status of the requestManager to complete. I have transaction management wrapped around each MDB so the update of the requestManager shouldn't be commited to the DB until MDB C has completed. Now, in MDB C its' first validation check is to see if the requestManger status is NOT complete, if already complete there's nothing to 'check' - so it returns. Now for this to work the only explanation I can think of is that the persistence is caching the requestManager so if five instances of MDB C are checking the status of the requestManager, remember that each MDB C is inside it's own transaction, they must be refencing the same instance of the requestManager.
I'm using Hibernate and from my understanding, it shouldn't share instances across transactions, i.e. if each MDB C instance is wrapped in it's own transaction, how can they share requestManager which is taken from the persistence layer (MDB C asks hibernate for the requestManger)?
Again, unsure if this is the right place for such a post.
Thanks,
Randall