I have posted this twice,so please excuse me.Could someone help me in this design problem?
We have a standalone batch process (a java class with a main()) which is run every night(a cron-like daemon runs this java class).This batch executes a query on a database ,puts the results(say 10 results) into an XML document(so we have 10 differnt XML docs) and pushes these XML docs as TextMessages into a weblogic JMS que.The MDB listenting to this que takes each XML document passed in the onMessage() and creates new records in another DB by directly calling CMP Entity beans.However,it so happpens that if we have pooled instances of the MDBS, one instance might process message x in the que,and another instance might process message x+1.If both these messages are essentially trying to create the same record ,we are going to get PrimaryKey Exceptions or some other exceptions. I hope i was able to paint a clear picture of our problem.Is it possible to solve this by setting BOTH the initial-beans-in-pool and max-beans-in-free-pool to 1...that way,we will NEVER have more than one instance of the MDB accessing the que.Ny other suggestions are most welcome.Is a MDB even a good way to accomplish what we want?
Thanks in advance,
Your problem would be solved by setting BOTH the initial-beans-in-pool and max-beans-in-free-pool to 1, as I have done it before. However, from your description, I wonder if it is necessary to use MDB, since your batch process will be run at really low traffic hour, and I really don't see the need to use JMS as no one care if you are using sync or async process at mid-night.
Thanks for your help! I tried setting both those parameters to 1,and it works fine on a single server env.However,since we need to deploy on a cluster with 3 servers, wouldnt we have 3 instance of the bean now,even though theres one instance on every server?I would then run into the same problems...is there any way to solve this? We are considering not using MDBs,but many other processes use that one,so would take some more time to decide.