Let me give a brief overview of my requirement.
The Web App has a functionality by name Bill Of Material(BOM) where the application users can update the information about the structure of a Manufacturing Part. There is no limit on the number of levels in the hierarchy of a Part. The Web App has a report screen where the user can choose an "entity"(well assume that an entity has been mapped to many parts) and ask for the report. The business logic for generating the report for an entity involves identifiying all the parts mapped to the entity and fetching the demand for each part. Fetching the demand for a part involves exploding the entire BOM hierarchy upwards and identifying the dependent demand (In simple terms, identify the parent parts demand and how many child parts make a parent). This process has to be done recursively until the top most parent is reached. This process has to be repeated for all the parts mapped to the entity.
We thought of invoking an Oracle Stored Procedure for exploding the entire BOM tree and identifying the total demand for a part. From our past experience, we guess that the procedure will take more time if the BOM tree has more levels. So, we have decided that to develop a batch job(again an oracle stored proc) which will explode the BOM and populate the data in a temporary table. The report usecase will use this temp table and display the report. But the problem arises while deciding when this batch job should be executed. Ideally the temp tables should be updated whenever the BOM tables are modified. Apart from BOM there are quite a few other scenarios which affect the report data.
This is our design as of now. The Business Classes which serve those usecases which affect the report data will spawn a new
thread just before returning data to the
servlet that invoked them. The new thread will invoke the Batch Job for updating the temp tables. This way the temp tables will always reflect the latest data. Suppose if the user asks for the report, a check is made to see if the batch job is running. Since we dont want to show inconistent data to the user, we'll show a message stating that the data is being refreshed. Once the batch job finishes, we'll display the report to the user.
There are certain issues that we foresee in this design.
Is it a good practice to spawn new threads in an Web App? Though the response will be displayed to the user and the batch job will be executed as a background thread, there is no guarantee from the spec in the execution order. There is also the possibility of the background thread not relinquishing control to the main thread. If someone keeps updating the BOM/other usecases which affect the report data continously, as per our design the report will not be displayed. Only when the batch job is not running, we will display the report. Is this a good design? Are there any flaws in this design? Is there a better design?
Please excuse me for such a long problem statement. I sincerely appreciate any pointers to a better design.
My Special Thanks to Ben Souther for his LongRunningProcess.war, which is the one that triggered my mind into thinking this way
Cheers,
Arvind
[ July 29, 2006: Message edited by: Bear Bibeault ]