We are in a process of architecting a new software. In which our requirement is to integerate EJB with Quartz scheduler. The process is to read bunch of mails, parse the xml files attached with it.The mails can be thousands.
Now the options I am thinking are :
1. Create a cron job which calls SLSB at specific interval. In turn session bean reads mail box through helper class and then parse it.
But here only 1 session bean processed, so 1 mail at a time.
Is there any way that instead of 1 session bean I can call no of beans from the pool and then then can process number of mails together.
2. Create a cron job which calls a class to read mails at specific interval. And then those mails delievered to a TOPIC and in turn Consumer(ie. message driven beans) process them asynchroneously.
Which one is the best solution. Is there any way to use multiple session beans instead of only 1 SLSB.
Here is an idea.
1. Create a class that implements Runnable. In the run method of the class, call the session bean method and ask it to do its work.
2. Create a main class that implements the StatefulJob interface and invoke the threads from this class. Keep some kind of static member var in the threading class so that all the threads can put their section of data into this common data structure. Do a join() on the main thread so that it waits till all the other worker threads complete. Make sure all the threads a successful and continue processing in the main job.
Another Option:. If you are using SLSBs use quartz to call the methods on the SLSB itself using the EJBInvoker class. Design the SLSB so that it takes some kind of a parameter that decides what subset of mail data it wants to work on. Schedule multiple such jobs together with different search parameters. That also gives you the effect of multi-threading.
Thank you Sowmya,
For good suggestion.
Your last option may not work, since I have a 1 job and and afte executing of that job I need multiple threads which will work with multiple session beans.
I was dealing with similar task recently, but with rather low message volume expected, so I have one-by-one processing applied. In my opinion, JMS seems to be good solution if you want have them processed asynchronously (assuming you have to run in container), of course if sending the message isn't more expansive than parsing itself ;). Afterall, maybe your app server supports multithreading, so you can use it.
I am also thinking of using threading instead of JMS or beans.
Actually i feel the solution can be a mix of all the solutions proposed here.
i am still not sure with some parts of the REQ,
a) do u already a have a bunch of emails in you hand and then decide to process all the xml,
b) or do u have some kind of listener that waits for the email to arrive and them starts the processing.
c) or do u wait for a specific interval of time and then collect the mails/xml and then process them.
a) do u want multiple session beans to work on the same xml or one instance of the bean processes one xml.
anyway here is one approach(i am assuming some things here)
First Chunk(divide) you email into so predefined groups(like 10 each) on some criteria eg size of attachement or some business driven REQ,
assuming you have 40 email to process
create 4 chunks of 10 emails each.
as swomya said spawn 4 thread now each invoking 1 session bean, now parse the xml(do some business validation as required, and push it into MDB for further complex processing like(pdf conversion, writing to IO device etc).
Hope this helps
I don't see any purpose of creating SessionBeans and MessageDriven beans after creating threads.
Mine is batch process.
The solution we decided is to use quartz to fire cron trigger and then to use Threads for spawning specific number of messages per thread.