[ w w w . S e n t i e n t T e c h n o l o g i e s . c o m ]
[Transaction Management]
[
written byResearch Staff, Sentient Technologies, LLC,
Overland Park, Kansas | Scott Tucker – Founder & CEO]
[An explanation of how transaction software works and how banks avoid server crashes along with examples that illustrate some of the positive aspects and risks involved in transaction management.]
As technology continues to advance and the world becomes more digitally entwined, the methods by which individuals and business conduct financial transactions increase. As such, it is important to understand the processes behind these transactions, how the software works, and, more importantly, how banks avoid server crashes when processing countless transactions each day. By defining transaction management, the author lays the foundation on which the processes of understanding and overseeing transactions follow. This paper aims to provide an explanation of how transaction software works and how banks avoid server crashes but goes a step farther by including examples that illustrate some of the positive aspects and risks involved in transaction management.
Transaction management is the overseeing process of a transaction manager that, by definition, is “responsible for coordinating transactions across one or more resources” (Red Hat 2). Typically, a transaction manager is built into a resource such as in enterprise-level databases used by banks where they manage transactions within the database. When transactions involve more than one resource, an external transaction manager is typically required. A transaction is an “operation that conceptually consists of a single step [but] must be implemented as a series of steps” (2). In banking, a transaction could be a customer transferring money from a checking to a savings account. While the customer’s actions are considered as one step, the transaction process actually involves several steps and this is where vulnerabilities in the system can occur (i.e. system failure). In the event of system failure, the steps are interrupted, leaving the system in an “inconsistent state” (2). Depending on the nature of the failure or severity of, for example, a system crash, the result can be serious and recovery may be difficult. In the process of transferring funds from a checking to a saving account, if a crash occurs after debiting a checking account but before crediting a savings account, the funds appear to disappear.
However, a bank can typically trace the transaction process and override steps to return funds to the original account.
A transaction, though singular in term, consists of several properties called ACID properties: atomic, consistent, isolated and durable. An atomic transaction is an “all or nothing procedure” whereby individual updates are assembled and either committed (completed) or aborted (rolled back or undone, uncommitted) when the transaction completes (Red Hat 2). A consistent state is the process where a transaction takes the system from one consistent state to another, while an isolated property involves partial results during a transaction being hidden from other entities accessing the transaction. Durable refers to a transaction’s persistent results.
In banking, a common term for transaction management programs is business transaction management (BTM) solutions. BTM solutions provide a real-time record of all transaction activity, which “requires transaction monitoring and tracking across multiple IT tiers” (Alon para. 8). Certainly, the foundation is a networked system of computers and server but there has to be software that both connects the full system and is designed to store, process and transfer data across multiple platforms to multiple commercial and individual users. The transaction
management software is designed to allow banks to see how each transaction moves from start to completion. However, as Alon points out, “banks must be able to establish specific business transaction profile metrics to pinpoint potential trouble spots and related business impact” (Alon para. 8). The software provides a way for banks to examine the details of what occurs at the back end whether the interaction is a process from within the bank or when a customer interacts with an application. The management software stores data such as time, location, user and a detailed map the serves and tiers that were used or accessed for each transaction. In reference to the earlier example of transferring money from a checking to a savings account, the bank can see the
to the savings account, which is especially helpful when encountering issues such as generalized unsuccessful or cancelled transactions and in the event of server crashes.
Each bank, however, has specific or individualized software needs that fit both banking and ATM processes. In today’s digitalized world, banks must meet a wide variety of institutional and consumer needs that require both web-based and installed software programs for its core banking system and processes or features such as ATM management, credit card processing, investment banking, loan submission control, multi-branch, online banking, private banking, retail banking, teller operations, and—of course, transaction monitoring. To illustrate the type of software a bank could use for specific needs, this writer searched for a program that will provide core banking and transaction monitoring needs for more than 1,000 users, finding Finacle by Infosys Technologies.
While programs vary according to the user’s specified needs, using the minimum criteria for core banking and transaction monitoring for web-based and installed software options, the solutions Finacle provides includes:
• Compliance Management • Core Banking System • Credit Union
• Custom User Interface • Customizable Fields • Customizable Functionality • Customizable Reporting • Data Import/Export • Data Integration • For Collections • Investment Banking • Lease Management
• Legacy System Integration • Lending Integration • Loan Submission Control
• Mobile Access • Multi-Branch • Multi-Currency • Multi-Language • Offshore Management • Online Banking • Private Banking • Reporting • Retail Banking • Securities Management • Software Development Kit • Teller Operations
• Time Deposits
• Transaction Monitoring • Workflow Management
Finacle’s platforms are Windows, web-based, Open Source, and Linux/Unix and the program’s company offers support services based on the bank’s needs whether around the clock, during regular business hours, or online and self service.
The greater the success or the more the need for processing customer requests the greater the risk for a sever crash. In banking, this risk is compounded as banks typically process
thousands to tens of thousands of requests each day. If the bank’s software and the hardware that supports the collective system are not capable of handling massive and often simultaneous transactions, it becomes overloaded and a crash is imminent. The Linux Journal reports on this very topic and recommends applying the queuing theory to examine a system’s current
capabilities and to project improvements the bank may need to make.
Queuing theory uses statistics to model server system behavior where the serve may or may not be a computer. A common area where the queuing theory would be applied in banking is the waiting queue at a bank teller. For example, a bank might use a single-service queue model with “exponential service times” (Francois para 4). Single server refers to a system or systems that has only one database server. Exponential service times refer to the random response time that “follows a known mean average with a standard deviation equal to that average” (para. 4). The process includes a specific formula using specific variables such as: “<lambda> = average number of requests per second; s = average service time for each request; <rho> = utilization: fraction of time that the server is busy; q = average number of requests in the server (waiting and being processed); tq = average time a request spends in the server (response time as perceived by the user); w = average number of requests waiting in the server” (para. 4).
Servers are designed to handle multiple transactions and stacked transactions per second, but, as with any computer program, will require updates or upgrades as the transactions increase.
If a bank’s system cannot handle the increased transactions a crash occurs. A crash can be related to specific or isolated area within the system or it can, in severe circumstances, apply to the complete system (i.e. a bank’s ability to process transaction may be down but workers may still be able to view customer data). Further, human error can lead to server crashes as illustrated in the following example of a teller or other automated queue:
When the number of requests coming in reaches the point where the utilization <rho> is almost 1, the number of requests waiting in RAM grows toward infinity. If you have 1,000 requests in RAM and each takes only 100KB (that is roughly 100MB), you are probably okay. With s = 0.05 second (50ms), q = 1000 when you have 71,928 requests per hour. When you have 71,993 requests per hour, you will have 10,284 requests waiting in RAM. That's about 1GB RAM. Let's say you have 2GB--with six more requests per hour, 71,998, you get q = 35,999. That's about 3.5GB. Theoretically, your users would have received a response after 30 minutes (1,800 seconds). But very few will get any response because the machine is swapping to get some virtual memory. Since this increases the service time by a factor of 100 or 1,000, your server appears to the world to have died. (Francois para. 10)
In these situations, customers tend to be impatient and generally will not wait 30 seconds. Most will click stop or cancel and then resubmit the request that only adds more requests to the queue. The only way to avoid this type of crash is for the bank’s IT technicians to perform routine monitoring processes and upgrade capabilities as the bank’s transactions grow.
In simpler terms, crashes tend to occur when resources run low. Banks initially plan for their needs and install software that is designed to meet those needs; however, the bank’s IT department should be consistent in examining growing needs and making recommendations to improve its system accordingly. Message logging and check pointing processes enable IT staff to monitor common areas where weaknesses are present and improve on those process areas
accordingly. For example, the bank’s IT department can examine logs to see where the system is having issues. The logs are similar to the logs used in a personal computer where the user can
view the history of errors logged by the system whether general or extensive (i.e. low resources, complications with a specific program within the overall system, outdated software, et al).
One study focused on what to improve failure-recovery options for a CORBA-based bank server that would provide fault tolerance features using message and checkpoint logging (Vassev 6). To satisfy the requirements to prevent crashes, the authors developed “a message-logging protocol for the branch servers of the distributed banking system to log required information; a recovery module that restarts the bank server using the message log to help the restarted bank server process subsequent requests for various operations; and a monitor module that
periodically checks whether the bank server is down and helps the recovery module restart the bank server if the latter has crashed” (6).
In terms of logging, however, there are other and more pointed definitions that apply to the prevention of server crashes. Message logging, for one, is “a common technique used to build systems that can tolerate process crash failures” (Vassev 6). Similar to the explanation provided earlier, these protocols periodically record its local state and log the messages received since recording that state (6). When one process crashes, a new process is created in its place and recorded. Vassev explains that “all message-logging protocols require that the state of a recovered process be consistent with the states of the other processes” where “the consistency requirement is usually expressed in terms of orphan processes” (6). Orphan processes are surviving processes that are in a state that is inconsistent with the recovered state of a crashed process (6). Message logging also includes factors related to the recovery and monitor modules. The recovery module “listens” to requests from all servers and the monitor module and processes requests using multitasking. The monitor module periodically checks the server process and restarts when necessary, registering a new server when it receives a register message.
While there are a number of processes involved in banking transactions and the risks increase as users and transactions increase, there are ways to maximize the banking experience and minimize risk of server crashes. A number of software options are available, one—as examined in this paper—being Finacle, which provides banks with web-based and installed features for core banking and transaction monitoring needs, among other needs. However, the bank’s IT department must work in cooperation with its systems and software vendors to ensure the bank’s technology and processes can handle the massive transactions it processes each day. By examining studies that have been conducted, this paper has illustrated ways message logging can detect and prevent crashes and ways that banks can monitor possible vulnerabilities to stop overloads before they occur and, when necessary, restart servers to ensure maximum ability to meet customer needs.
[Works Cited]
Alon, Amir. “Business Transaction Management: Key to Online Banking Success.”
E-Commerce Times. Web. 9 November 2007.
<http://www.ecommercetimes.com/story/60228.html> 21 November 2013. “Finacle.” Capterra. 2013. Web.
<http://www.capterra.com/banking-systems-software/spotlight/59348/Finacle/Infosys%20Technologies> 21 November 2013. Francois, John T. “Why Application Servers Crash and How to Avoid It.” Linux Journal. 29
January 2002. Web. <http://www.linuxjournal.com/article/4878> 21 November 2013. Red Hat. “Basic Transaction Concepts.” EIP Transaction Guide, Version 7.1. December 2012.
Web.
<https://access.redhat.com/site/documentation/en-US/Fuse_ESB_Enterprise/7.1/html/EIP_Transaction_Guide/files/front.html> 21 November 2013.
Vassev, Emil, Que Thu Dung Nguyen, and Heng Kuang. “Fault-Tolerance through Message-logging and Check-pointing: Disaster Recovery for CORBA-based Distributed Bank Servers.” Concordia University. Web. 15 April 2006.
