Transaction Design Pattern for MVC – Responsibility Location

Your first example is the right one.

if (action == "insert") Model.insert(data)

But you should try to think of it this way: You have an application, and any interface to it (UI, tests, CLI, etc) is simply that - just an interface.

Interfaces to an application tell it what to do, and get data back from it. That's all they do.

So your interface in this example is the controller. The fact that the controller takes the application's output and renders it inside an HTML template is allegedly "coincidental".

On another note, I know you said you're not going to use any existing framework, but you should at least keep the following in mind:

1. Learning how to use a framework is not always smooth and easy, but it's going to take you less time than trying to implement the set of features yourself.
2. You might not be aware yet of all the pitfalls you're going to encounter. These are all covered, in one way or another, in big MVC frameworks.
3. You might not (and probably don't) know all of the current or future requirements for your application. But frameworks already let you develop something simple today and make it easy to add new features tomorrow (because they're built-in, and built so they'll be easily integrated at any point).

I saw your "language-agnostic" examples were pretty much Python. If you like the language, you should know that Django is one of the biggest and most documented MVC frameworks (in general, not just in Python).

I'd say 99 times out of 100 the answer is to grit your teeth and re-use the existing COBOL code. It sounds like it might have some fairly complex logic behind the scenes; unless you actually have an up-to-date and accurate spec you might have trouble re-producing the logic in all its nuances. This is bad mojo on a financial application as the bean counters will want bug-for-bug compatibility with the legacy code.

So, as a first stop, I would suggest that you seriously investigate what is needed to wrap your legacy process or integrate it with the front-end. You might take a look at the COBOL-Java integration options available from Micro Focus.

If you really can't re-cycle the existing code then you have a significant problem. While a sproc might well do what you want, you have the problem of making something mimic the exact behaviour of an apparently complex and probably poorly documented COBOL application.

Unless your replacement process is radically slower, wrapping 2000 DMLs in a transaction isn't going to be a major issue. It's possible to wrap entire ETL processes in a transaction and have them roll back on a failure. I have seen an application where it was necessary to do this, although it is unusual. Splitting a financial transaction is a no-no, especially on a double entry system. In almost all cases it should commit or roll back atomically. Stick with the single transaction.

The fact that the COBOL application does computations one DML at a time and uses the results in the next step of the computation does not bode well for conversion to set operations. Be prepared to have to do this row-by-row and find a way to make it run fast. A stored procedure may well be the way to do this. You don't say what DBMS you're using (DB/2 for Z/OS?).

Also, you might have to drop down to XA transactions (java.transactions API) and JDBC, especially if you need to work in the client layer. If you want good performance on 2000 row based operations you might have to go below the framework.