In previous blog entries I have talked about transaction scope, how DB2 Java applications access the database too much and transaction units of work (UOWs) are not really analyzed properly.
Too often these days the design and development are done in an Agile or SCRUM type of project methodology where short concise project deliverables are designed and deliver working transactions. These methodologies are good for transactions but sometime are not good at overall performance. Since the scope of the Agile or SCRUM sessions are individual transactions, the big picture of the overall business and processing objectives sometimes gets lost. This leads to transactions that only accomplish a small discrete piece of the business. Other transactions are necessary and retrieve the same master customer or product information again and again in order to complete the processing activity.
Database caching can mitigate and shield the impact on performance for repeatedly getting the same database information but cannot cache all the activity. When analyzing your various transactions, determine the overall business objectives and flow. Combine standalone transactions that use the same data keys as much as possible.
Leave a Reply