There is a huge debate/discussion going on recently on a project I’m on. Basically, the project is like 1/5 into development and there is little or no direction on handling transactions. What is there is directly managing them from the business delegate…which is ok…if handled properly. They aren’t playing nicely with others (seeing if one already exists, not committing if didn’t start, etc).
The biggest voice advocating that a standard or reusable pattern emerge is recommending an approach that would wrap the entire web request in a transaction (if the associated request would result in a call to a delegate that need to be executed in the context of a transaction). I really don’t want to settle with this as the only method for identifying/handling transactions. The delegates are written to be reused…and, in part, to encapsulate (and insulate the caller from) the underlying details. By having the delegate just assume it is running in the context of a transaction and/or forcing all calling code to know that a transaction is required will break that encapsulation and inevitably lead to breakages.
I agree that handling the transactions in the code is not easy (when done properly and thought through), and it can be messy. This is why I (and many others) like(d) session beans…and spring’s declarative transaction management. We don’t have the luxury of spring on the project, but we can easily implement a template approach (a la spring jdbc layer), or even more directly, just factor out the start/end/rollbackonly transaction logic into a helper class. The decision is leaning heavily toward the last. I didn’t propose that solution, but it is a good on for our case. The delegates still start/stop transactions, but it is much cleaner (much of the detail is handled in the helper). This allows for those who feel the entire web request should be handled in a transaction to still do that, but when the delegate is reused in a different (possibly non-request related) context, the behaviour will be predictable (won’t break).
