Core / Corporate Banking Systems do not perform due to the lack of design provisions to ensure unhindered parallel processing of OLTP and Bulk Transactions. The Primary Reason is the lack of resource release controls in Nested Transactions in today’s databases.
Nested Transactions have one encompassing parent transaction and ‘n’ number of nested – child transactions, together forming one large logical transaction. Parent has a Begin Transaction event and a Commit Transaction event. Within these two parent level events, every nested transaction has it’s own Begin Transaction and Commit Transaction Events. In databases, the database row (account) involved in a nested transaction, does not get released (unlocked) even after the nested tran commit and hence all the accounts involved will stay locked till the Parent Commit Tran happens. This is the core of the issue and due to this all other OLTP / Bulk trans which involve these locked a/cs will have to wait and they will generate huge amount of ‘Try to Acquire Lock’ calls resulting in sudden degradation of system perf.
BPDP can be used to resolve this nested trans issue. BPDP does not use database provided nested transaction feature. BPDP breaks the parent transaction into two transactions: one header transaction with its own Begin and Commit and one Footer transaction with its own Begin and Commit. All transactions in the Bulk Transaction will be processed after the header transaction and before the Footer transaction and all of them have their own Begin and Commit. Hence all accounts involved in these transactions are released (unlocked) with the commit of their own individual transaction. Now the problem to be solved is the requirement of NOT allowing transaction effects on these accounts, till the entire Bulk Transaction has been completed (till the commit of the Footer) and the provision to roll back the entire Bulk Transaction, if required due to any functional requirements. This problem now becomes a Resource Management issue. If you take the example of a Bulk Salary Posting: Accounts that get Credits must have the credit amount blocked till the end of the Bulk Transaction and after the bulk transaction ends and need for bulk transaction roll back is not required, then these blocked credits need to be released as individual transactions again, with their own Begins and Commits. Dependent Debits must be processed using the Blocked Amount from the Credit processed in the Bulk Transaction.
This BPDP approach with real-time transaction throttling linked to current system load has been used by Patterns in Enterprise level banking systems processing hundreds of thousands of Bulk Files together with huge OLTP loads. The BPDP pattern is used when a Bulk Processing SOP is Hyper Automated using a Patterns Bot Worker.
