From Journeyman to Master

Jeff said:

“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.

Yes, I heard that this problem is being dealt with using nested transaction supported by Toplink. But I think it might be an overkill for us. Do we really need nested transaction? Do we need to do partial commit/rollback? It doesn’t solve the duplicate lookup issue, either. It’s gonna be one more thing that ties the application to Toplink. So I like putting the workflow stuff behind the facade idea better. Actually, there is a class called InTransactionTaskBundle that does just that. It performs as same as any other TaskBundle except that it’s behind the facade and uses domain objects directly. I created this class and refactored a process bundle with about 10 tasks. The refactoring was straightforward and took only one or two hours.