Our project has the first release date set to be March of the next year. Currently, every team other than the one I’m in is in scenario testing or performance tuning mode. I’m not quite sure how things are going with them. But I myself can see a couple things that will bite us if they are not dealt with before or soon after the release.
Process bundle
Process bundle is a pattern we use to group tasks that need to be executed together and in order. It’s done as something like this:
class ProcessBundle {
public void doTask() {
FacadeFactory.getFacade().doTask1();
FacadeFactory.getFacade().doTask2();
.
.
.
}
}
Note that each facade method has its own transaction. So if one of the task fails, it will just rollback itself, not the whole bundle. If some other process modifies the result of task 1 between the time task 1 finishes and task 2 starts, task 2 will have incorrect input. Since most of the tasks in a bundle use the same set of domain objects, we are also doing some duplicate lookup here.
Batch
So you develope a perfect, highly responsive web based enterprise application and release it to the client. What’s the first thing that’s gonna pop up? The client wants a batch process like the one they had in the good old mainframe system! That just throws the whole perfectionism away, doesn’t it? But you gotta face the reality. A batch process is even more important in a web environment. Say our application takes 5 minutes to process 100 wells. It’s not unusual for our client to process thousands of wells at a time. Being an optimistic person as I am, I say it’ll take half a hour to process those wells. Now you are facing a web browser or session timeout issue. What if somebody clicks the Back or Refresh button? Most of the enterprise level web applications will face the same problem. What do you do? Well, first you implement a job queue. Then you create a super responsive web page to monitor and maintain it.
That’s my thought. Welcome any comment.
“Note that each facade method has its own transaction. So if one of the task fails, it will just rollback itself, not the whole bundle.”
I thought about this as well, but just assumed it had been addressed before. Maybe it hasn’t been brought up, though?
I also wonder if this is one way we could get some good performance gains. If we could come up with a way of injecting one Unit of Work into multiple facade calls we could address the rollback issue, and possibly make things faster by not ditching our object caches after each facade method (transaction).
For example, our battery oil process task bundle must make about 10 separate facade calls. Perhaps our workflow stuff should sit just below the facade instead of above it.