US20020107743A1 - Transaction processing system having service level control capabilities - Google Patents
Transaction processing system having service level control capabilities Download PDFInfo
- Publication number
- US20020107743A1 US20020107743A1 US09/942,215 US94221501A US2002107743A1 US 20020107743 A1 US20020107743 A1 US 20020107743A1 US 94221501 A US94221501 A US 94221501A US 2002107743 A1 US2002107743 A1 US 2002107743A1
- Authority
- US
- United States
- Prior art keywords
- service
- execution
- processing
- transaction
- services
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
- 238000012545 processing Methods 0.000 title claims abstract description 142
- 238000001514 detection method Methods 0.000 claims abstract description 16
- 238000000034 method Methods 0.000 claims description 133
- 230000008569 process Effects 0.000 claims description 128
- 238000012913 prioritisation Methods 0.000 claims description 7
- 230000007423 decrease Effects 0.000 claims 1
- 238000010586 diagram Methods 0.000 description 19
- 238000007726 management method Methods 0.000 description 7
- 230000001965 increasing effect Effects 0.000 description 6
- 238000006243 chemical reaction Methods 0.000 description 5
- 238000004891 communication Methods 0.000 description 4
- 230000008859 change Effects 0.000 description 3
- 230000003247 decreasing effect Effects 0.000 description 3
- 230000006870 function Effects 0.000 description 3
- 230000004044 response Effects 0.000 description 3
- 230000015654 memory Effects 0.000 description 2
- 238000012946 outsourcing Methods 0.000 description 2
- 230000004913 activation Effects 0.000 description 1
- 238000013459 approach Methods 0.000 description 1
- 238000012217 deletion Methods 0.000 description 1
- 230000037430 deletion Effects 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 230000002708 enhancing effect Effects 0.000 description 1
- 230000000977 initiatory effect Effects 0.000 description 1
- 230000007246 mechanism Effects 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q10/00—Administration; Management
- G06Q10/10—Office automation; Time management
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q10/00—Administration; Management
- G06Q10/10—Office automation; Time management
- G06Q10/109—Time management, e.g. calendars, reminders, meetings or time accounting
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/08—Payment architectures
- G06Q20/20—Point-of-sale [POS] network systems
- G06Q20/204—Point-of-sale [POS] network systems comprising interface for record bearing medium or carrier for electronic funds transfer or payment credit
Definitions
- the present invention relates to a transaction processing system, and in particular to implementation of transaction processing in response to requests from plural customers.
- the transaction system is a system for efficiently executing a lot of processing requests in such a manner as to assure consistency in a basic line of corporate information system such as financial trading and ordering/order receiving.
- a client/server system is so constructed that a client (terminal) issues a request and a server executes the main body of transaction processing by accessing a database as required.
- a processing program executing an actual transaction on the server is called service.
- the service providing side in the transaction system is called a service provider.
- a service provider For example, in the retailing bank business, ATMs or tellers are clients, and the basic system including a customer's account database is a server.
- the bank is the service provider, which provides services such as withdrawal and deposit transactions.
- Transaction processing middleware used on the server side is a transaction monitor.
- the transaction monitor mainly takes the following two parts.
- the transaction monitor receives processing requests sent from clients and queues the processing requests by taking into account request priorities and crowding levels on the server to forward control of the respective requests to appropriate server programs (service) one by one, thus making effective use of server resources.
- the transaction monitor detects errors or faults caused during execution of processing. If the processing has completed successfully, it carries out result writing (committing) operation, while if the processing has not completed successfully, it carries out cancel (rollback) or re-run operation. Thus the transaction monitor assures consistency of the transaction processing.
- FIG. 18 shows a typical configuration of the transaction monitor.
- a transaction monitor 209 is located on a server 215 , while client programs 201 , 202 issuing processing requests are located on client terminals 221 , 222 , respectively.
- the server 215 is a UNIX server, a mainframe computer or the like, while the client terminal is a personal computer, an ATM terminal or the like.
- the transaction monitor 209 includes request queues 210 and 211 , a scheduler 204 and a transaction execution module 207 .
- the processing request for a service is typically transferred from the client 221 or 222 to the server 215 in the form of a message (electronic text). Therefore, the transaction monitor has a communication function module so that the transaction monitor receives a processing message by controlling its own communication function module.
- the message received is stored in the transaction monitor 209 as a processing request. Since two or more requests are usually kept waiting in the transaction monitor 209 , the transaction monitor 209 uses the queues 210 , 211 as a First-In First-Out data structure to store the requests in the order of input. The requests stored are extracted from the queues 210 , 211 in the order of storage as soon as one of resources (CPU, memory etc.) in the transaction execution module 207 becomes available, and processed by corresponding service programs 206 .
- resources CPU, memory etc.
- Scheduling is to extract a request from a queue and move the request to the execution of service program processing for the request. Efficient scheduling is necessary to increase the efficiency of the transaction processing system.
- requests 301 to 309 are stored in a request queue 300 . These requests are supposed to be processed by processes 310 to 313 one by one.
- the term “process” is a unit of program to be processed on a computer, and the unit is a combination of one virtual address space, a program loaded on the space, data and a CPU register indicative of an execution state of the program.
- the same transaction processing program (service program) is loaded in all the processes. If free spaces are available in the CPU of the computer, the number of services to be provided concurrently is increased by increasing the number of processes so that the utilization factor of the CPU can be improved.
- FIG. 19A shows a case where a very small number of requests are stored in the queue 300 .
- the transaction monitor allocates a small number of processes ( 310 , 311 ) to the service concerned according to the number of requests.
- FIG. 19B shows a case where a large number of requests arrive and hence the number of requests queued in the queue 300 increases.
- the transaction monitor monitors conditions in the queue to increase the number of processes to be allocated to the service ( 310 to 313 ).
- FIG. 19C shows a case where incoming messages are reduced and the length of the queue becomes short.
- the transaction monitor deallocates the idling process 313 from the service and allocate it to another service or task.
- By associating the length of the queue with the number of processes to be allocated it becomes possible to improve transaction efficiency within a range of CPU resources.
- a system shown in FIG. 20 is used for balancing load among servers.
- Example applications of the transaction monitor for a further advanced multi-transaction processing system include a message broker.
- a normal transaction processing system has a one-to-one correspondence between a message and a service, but a message broker performs processing by passing one message among plural services by recursively invoking.
- the message broker stores in the transaction monitor a service flow (business flow), which designates what services and in what sequence the services are invoked for the message.
- the services to be invoked may be located on the same server as the transaction monitor or another independent stand-along server.
- FIG. 21 shows a configuration of the message broker.
- Client programs 501 , 502 from which processing requests are issued are located on client terminals, respectively.
- a transaction monitor 509 is located on a transaction processing server.
- Service programs A 530 and B 531 for providing business services are loaded on different servers (or the same server).
- the terminals and the servers are connected with each other through message communications lines.
- the transaction monitor 509 includes request queues 510 , 511 and a scheduler 504 for deciding the sequence of request processing.
- the message broker adds an extension to the transaction execution module ( 207 in FIG. 18) to constitute a service flow execution routine 507 .
- the service flow execution routine 507 manages the execution of a service flow defined by the service provider, not just initiate and execute a service program according to a message.
- the message broker allows the execution of a service flow on the transaction monitor, it can combine plural service programs to construct more complicated service structure.
- One method is to divide the processes executing the service flow into two groups (active group and standby group).
- the active group executes the unchanged flow while re-loading a new service flow to the standby group.
- message routing is switched from the active group to the standby group in the continuation of the system's operation.
- Another method is to provide routing enable and disable modes for each service node.
- a node to be replaced is changed to routing disable mode, thereby prohibiting input of any message to the node upon re-loading of a new service flow to the node.
- JP-A-09-062624 Japanese Patent Laid-Open Application No. 09-062624 (JP-A-09-062624) (Processing System for On-line Transaction); Japanese Patent Laid-Open Application No. 06-243077 (JP-A-06-243077) (Distributed Transaction Processing System); Japanese Patent Laid-Open Application No. 08-063432 (JP-A-08-063432) (Transaction Batch Processing System in Consideration of Priority); Japanese Patent Laid-Open Application No. 06-052121 (JP-A-06-052121) (Batch processing-Real Time Processing Sorting Type Transaction Processing System); Japanese Patent Laid-Open Application No.
- JP-A-07-073143 (Time Band-Based Priority Control Transaction Processing System); and Japanese Patent Laid-Open Application No. 10-040117 (JP-A-10-040117) (Task Control type On-line Transaction Processing System for Maintaining High Response).
- Such a data center is operated under service level agreements (SLA) with service providers to bill the service providers according to the computer resources used (the amount of transaction, associated CPU operating time, data amount, etc.) and service guaranty conditions. To reduce the billing, it is necessary to execute more transactions with fewer computer resources (investment).
- SLA service level agreements
- the above-mentioned conventional message broker or transaction monitor needs to be provided with an auxiliary process group or routing closing means for updating the service flow due to an update or addition of business services.
- the conventional message broker or transaction monitor does not allow for effective use of computer resources among plural clients, which makes flexible operation difficult.
- a representative mode to be disclosed in this specification is a transaction processing system comprising: means for holding or storing priority conditions defined according to services the transaction processing system provides; queuing means for storing processing requests sent from clients for the services while putting the respective services into a particular order; means for obtaining waiting conditions of the stored process requests from the queuing means; and means of execution prioritization for deciding execution priorities to the processing requests input from the clients to the transaction processing system by referring to the priority conditions and the waiting conditions of the processing requests.
- the queuing means is provided with plural queues each of which can store processing requests from each customer or user to which corresponding service is provided. It is also preferable that the means for storing priority conditions contains priority conditions defined according to the type of processing (service to be executed) and the customer or user.
- the transaction processing system further comprises means for detecting throughput to a transaction to control the allocation of computer resources to each service, and means for allocating transaction processing processes to the service, wherein the means for allocating processes decides the allocation of processes to the service by referring to the process request waiting conditions obtained and the transaction throughput detected.
- the transaction processing system further comprises means for storing an identifier or identifiers of one or more execution modules constituting each service, and means for managing an update of each execution module on the basis of the identifier, whereby when the update managing means executes the update of the execution module, the updated execution module is placed (loaded) to storage means prior to starting the transaction corresponding to the service.
- the transaction processing system or message broker carries out priority control to each service in consideration of priority conditions defined according to the services the transaction processing system provides, and processing request waiting conditions obtained from the queuing means for storing processing requests sent from clients for the services while putting the respective services into a particular order.
- the transaction processing system further comprises means for detecting throughput to a transaction corresponding to each service, and means for allocating a transaction processing processes to the service, wherein the means for allocating the processes decides the allocation of processes to the service by referring to the process request waiting conditions obtained and the transaction throughput detected.
- the transaction processing system further comprises means for storing an identifier or identifiers of one or more execution modules constituting each service, and means for managing an update of each execution module on the basis of the identifier, wherein when the execution module or modules have been updated by the update managing means, the updated execution module or modules are placed in the storage means prior to starting the transaction corresponding to the service.
- FIG. 1 is a block diagram showing a general structure of one preferred embodiment according to the present invention.
- FIG. 2 is a block diagram showing a hardware structure of the embodiment according to the present invention.
- FIG. 3 is a table showing an SLA database.
- FIGS. 4A to 4 D are tables showing a message dictionary, in which
- FIG. 4A shows a fixed part definition module
- FIGS. 4B to 4 D show variable part definition modules.
- FIGS. 5A and 5B are descriptive diagrams of a service flow, in which
- FIG. 5A shows a relationship between node and service program
- FIG. 5B shows a relationship among node name, node type, input source, output destination and module.
- FIG. 6 is a diagram showing data structure of a message.
- FIG. 7 is a diagram for explaining a configuration of a request queue.
- FIG. 8 is a PAD diagram showing operations of the request queue.
- FIG. 9 is a PAD diagram showing operations of a queuing condition detection module.
- FIG. 10 is a PAD diagram showing operations of a scheduler.
- FIG. 11 is a diagram showing a configuration of process management information.
- FIG. 12 is a PAD diagram showing operations of a dynamic loader.
- FIG. 13 is a diagram showing a configuration of an execution module condition table.
- FIG. 14 is a PAD diagram showing detailed operations of the dynamic loader.
- FIG. 15 is a PAD diagram showing operations of an execution module manager.
- FIG. 16 is a block diagram showing a second embodiment according to the present invention.
- FIG. 17 is a PAD diagram showing operations of a process management module according to the second embodiment of the present invention.
- FIG. 18 is a block diagram showing a conventional transaction processing system.
- FIGS. 19A to 19 C are diagrams showing conventional process number control, in which
- FIG. 19A is a case where there exists one request
- FIG. 19B is a case where many requests are waiting
- FIG. 19C is a case where the requests are reduced.
- FIG. 20 is a diagram showing conventional priority control.
- FIG. 21 is a block diagram showing a conventional message broker.
- FIG. 2 shows a hardware structure of a computer system according to one preferred embodiment of the present invention.
- the system is constructed of one or more client terminals 701 , 702 , one or more transaction servers 703 , and one or more service program executing servers 704 , 705 . It should be noted that the same computer may be used commonly for the transaction processing server and the service program executing server.
- the client terminals 701 , 702 may be ATM (Automatic Teller Machine) terminals or personal computers on which operating systems such as Microsoft Windows or Linux can be run.
- ATM Automatic Teller Machine
- the transaction processing server 703 and the service program executing servers 704 , 705 are, for example, UNIX servers like Hitachi 3500 series, Windows NT servers (trademark) like Hitachi Flora (trademark) series, or mainframe general-purpose computers like Hitachi MP series.
- Communication lines 710 connecting the clients and each server are, for example, general-purpose networks such as the Ethernet.
- the transaction processing server 703 and the service program executing servers 704 , 705 are equipped with storage means such as memories or hard disks, not shown.
- Client programs 101 , 102 are run on the client terminals 701 , 702 , respectively.
- the client programs provide interfaces with terminal users in the system. It should be noted that the term “client” denotes the customer-specific client terminal 701 or 702 to be connected to the transaction processing server 703 .
- the above-mentioned client programs correspond to ATM control programs or client programs for personal computers.
- the client programs may be Web browsers.
- Each client program builds up a message in response to input from an end user to send the message to a transaction monitor 120 .
- the transaction monitor 120 is a key feature of the embodiment. Unlike the conventional transaction monitor 120 , the transaction monitor 120 of the embodiment can receive messages (processing requests) to plural service providers (hereinafter, also referred to as customers). It is assumed in FIG. 1 that the number of service providers is two.
- An SLA database (priority condition database) 113 stores contract conditions (SLA) related to service levels (priority conditions, allowable waiting time) under contract with each service provider. For example, based on such contract contents that “transactions for service provider A should be processed in 10 seconds or less,” an allowable waiting time of 10 msec. and priority U.L may be stored in the database.
- a format of messages from each service provider is defined in a message dictionary 114 .
- a definition that “10 th to 20 th bytes in a message from service provider A describe customer account number” may be stored.
- Definitions of a service flow for each service provider are stored in a service flow definition module 115 .
- a group of execution modules corresponding to respective service nodes of the service flow are stored in an executing module library 116 .
- a preprocessor 103 interprets a message from the client server 101 or 102 to judge which service provider the message belongs to.
- Each of request queues 110 , 110 is provided for each service provider (each customer) that accesses the transaction monitor 120 ; it stores requests sent to the service provider. Since it is assumed in FIG. 1 that the number of service providers is two, there exist two request queues 110 , 111 .
- a queuing condition detection module 112 monitors the request queues 110 , 111 to obtain their conditions (the number of waiting requests and throughput).
- a scheduler 104 decides scheduling priority in consideration of queuing conditions obtained from the queuing condition detection module 112 and the SLA contract conditions stored in the SLA database 113 .
- the scheduler 104 also manages the number of processes 108 , 109 allocated for each service provider to decide a proper number of processes which meets the SLA contract.
- the messages taken up by the scheduler 104 are sent to a dynamic loader 105 .
- the dynamic loader 105 decides a service flow corresponding to the current message by referring to the service flow definition module 115 .
- An execution module manager 106 monitors the executing module library 116 to detect an update if any.
- the dynamic loader 105 refers to the detection results to judge whether service nodes needed for execution of a service corresponding to the current message have been already loaded in the current process. If not loaded (or old modules remain loaded), a new group of modules are loaded. Then a service flow execution routine 107 executes the service flow scheduled.
- the SLA database 113 is stored on a disk in the form of a table.
- a data center operating the transaction monitor 120 accumulates contract contents under contract with customers (service providers) in the SLA database 113 .
- the first row in the table contains column heads of Service Provider's Name 801 , Service Name (Processing Type) 802 , Class 803 , Upper Limit 804 and Priority 805 .
- Service Provider's Name 801 lists names of service providers as processing contract targets of the transaction monitor. This column may contain any character string as long as it is a unique name.
- the column below Service Name 802 lists names of services provided by the corresponding service providers through the transaction monitor.
- the column below Class 803 represents types of contracts with the respective service providers, where “B.E.” stands for “Best Effort” to indicate such a contract item that the transaction should be scheduled as long as resources are available. In this case, if the resources are crowded with other transactions, the transaction might be kept waiting a long time.
- “U.L.” stands for “Upper Limit” to indicate a contract item which decides on the upper limit of transaction waiting time.
- Priority 805 represents priorities to services under the “U.L.” contract. If the resources are so crowded that the “U.L.” contract cannot be satisfied, scheduling of services is carried out in order of precedence. It should be noted that Priority 805 may be decided according to the contact with each service provider or the data center side may independently assign priorities to service providers as customers or to services.
- FIG. 3 shows a basic structure of the SLA database.
- the data center can independently set other items, for example, such as priority according to processing load on each service.
- the preprocessor 103 and the scheduler 104 refers to the priority conditions stored in the SLA database 113 .
- the scheduler 104 (means of execution prioritization) searches the SLA database 113 for a service provider's name and service name on the basis of service identification information as search criteria in a manner to be described later to read in the priority conditions.
- the message dictionary 114 stores definitions of a message format for each service provider and each service.
- Each of messages the transaction monitor 120 receives is composed of a fixed part ( 1001 , 1002 in FIG. 6) and a variable part ( 1003 in FIG. 6).
- the fixed part contains message fields unique to the transaction monitor 120 while the variable part contains a message field varied by each service provider and each service.
- the message dictionary 114 also contains a fixed part definition module (FIG. 4A) and variable part definition modules (FIGS. 4B, 4C and 4 D).
- the fixed part definition module has columns of Starting Byte ( 901 ), Length ( 902 ) and Type ( 903 ), indicating that the service provider's name is stored in a 32-byte field from zero byte, and the service name is stored in a 32-byte field from the 32 nd byte.
- the 64 th byte and the following bytes belong to the variable part.
- variable part definitions are made by combining a variable-part index definition module (FIG. 4B) with variable-part field definition modules (FIGS. 4C and 4D).
- variable-part index definition module is formed into a table for use in searching indexes of the variable-part field definition modules on the basis of the service provider's name 905 and the service name 906 (service identification information) entered in the fields 1001 , 1002 of the message fixed part. For example, in FIG. 4B, the index for “service provider A” and “service A1” is “1.”
- Each table index sets fields of Starting Byte, Length and Data Type.
- FIG. 4C shows that the account number is stored in a four-byte field from the 64 th byte, the time stamp is stored in a 12-byte field from the 68 th byte, and the withdrawal amount is stored in an 8-byte field from the 80 th byte.
- FIG. 4D also shows the same except that the 8-byte field from the 80 th byte corresponds to the current balance.
- the definition modules allow the transaction monitor 120 to judge, from the fixed part 1001 , 1002 of the message, which service provider and which service the message belong to. Further, in the variable part 1003 of the message, parameters of the service can be set.
- the service flow execution routine 107 is formed by connecting individual processes on the basis of the message entered. Combining plural processes (processing nodes), each of which has its own purpose, makes it possible to realize a complicated function.
- FIG. 5A shows a service flow consisting of five processing nodes 601 to 605 , in which arrows indicate a flow of the message between nodes.
- the node 601 receives the message from a terminal via the transaction monitor, and forwards the message to the processing node 602 .
- the processing node 602 refers to the message to perform processing defined by the user while modifying the message if required, and forwards the message to the downstream nodes 603 , 604 and 605 accordingly.
- the node 603 is a message conversion node that performs code conversion of the message according to the coding format of a service program on the output destination side (for example, it performs conversion from EBCDIC code to ASCII code).
- the nodes 604 and 605 are output nodes from which the message is send out to external service programs via the transaction monitor.
- FIG. 5B shows information on the service flow definition module 115 .
- Columns 620 to 624 represent definition conditions for the nodes 601 to 605 , respectively.
- the service name specifies a service name to which each node belongs.
- the node name specifies any node name in such a manner that the node name is determinately defined in the flow.
- the node type selects and specifies an appropriate one of the node types provided in the message broker system from among the node types, such as input node, processing node, conversion node and output node.
- the input source and the output destination specify a node name as input source and output destination to and from the node specified in the corresponding “Node Name” column.
- the node B 602 receives the message from the node A 601 , and output the message to the node C 603 and the node E 605 .
- the processing node and the conversion node have individual processing contents specified.
- the service flow definition module 115 and the service flow execution routine 107 allow the execution of the service flow on the transaction monitor, which in turn makes it possible to construct a message broker capable of providing more complicated services by combining plural service programs.
- the executing module library 116 stores execution module groups needed for executing each service node in the service flow.
- Each execution module can be stored, for example, in the UNIX file format.
- the file name is made correspondent with the module name appearing in the service flow definition module, which makes it possible to retrieve a corresponding execution module from the service flow.
- the execution module is created in such a format that it can be dynamically loaded during execution, for example, in the UNIX DLL (Dynamic Loading Library) format.
- UNIX DLL Dynamic Loading Library
- the request queues 110 , 111 are data structures for storing messages input to the transaction monitor 120 in the order of input.
- the request queues 110 , 111 is created exclusively for each service provided by each service provider registered in the transaction monitor 120 .
- FIG. 7 shows the structure of each request queue.
- the request queue is constituted of a request header 1114 to 1116 provided one for each queue, and plural request structures 1101 to 1104 connected from the request header in a list structure.
- the request header contains fields of service information 1114 , SLA information 1115 , backward chain 1116 , queuing top pointer or start address 1117 and queuing information 1118 .
- the service information field 1114 is for storing a service provider and service name allocated to the queue.
- the SLA information field 1115 is for storing an SLA definition module stored in the SLA database 113 .
- the SLA definition module is retrieved from the SLA database 113 on the basis of the service provider and service name and stored in the request header.
- the backward chain field 1116 is for storing pointers to connect the request header with the other request headers in a list structure in case of the presence of plural queues.
- FIG. 7 shows such condition that plural request headers 1130 to 1132 are connected using backward pointers.
- the queuing top pointer or start address field 117 is for storing a pointer or start address to the top request structure of each queue (first created request structure in each queue).
- the queuing information field 1118 is for storing request conditions queued in each queue. Directions for use of the queuing information 118 will be described later.
- Each request structure contains four fields 1110 to 1113 .
- the time stamp field 1110 indicates the time of creation of each request.
- the forward and backward chain fields 1113 and 1114 store pointers for linking request structures with one another to form each queue.
- the message pointer field 1115 stores a pointer or address to an area in which the message main body is stored.
- Chains 1101 to 1104 show such condition that the request structures form a queue in forward and backward chains.
- Message storage areas 1120 to 1123 correspond to respective requests, and pointed by each message pointer stored in the corresponding request structure.
- the preprocessor 103 compares a message input to the transaction monitor with the contents of the message dictionary 114 to analyze which service provider and which service the message belong to. As a result of the analysis, the message is stored in an appropriate request queue 110 or 111 .
- FIG. 8 shows an example of an operation flow of the preprocessor.
- the preprocessor 103 Upon activation, the preprocessor 103 reads information on the message fixed part ( 1001 , 1002 in FIG. 6) from the message dictionary 114 ( 1201 ).
- the preprocessor 103 enters a loop 1202 to receive messages from clients until the transaction monitor 120 finishes providing services, and becomes a message input waiting state ( 1203 ). After completion of providing all the services, the preprocessor 103 may exit from the loop 1202 or perform interrupt processing to break the loop.
- the message input waiting state can be realized, for example, by the UNIX accept system call.
- the preprocessor 103 uses the message fixed-part information already read in the step 1201 to extract service provider's name and service name corresponding to the message ( 1204 ).
- the preprocessor 103 searches the request headers one by one ( 1205 ) to retrieve a queue corresponding to the service provider's name and service name obtained ( 1206 ) so as to resister the message (electronic text) input to the queue.
- the registration of the message can be carried out-such that a new request structure ( 1110 - 1113 in FIG. 7) containing the message, the service provider's name and the service name is created, and put at the tail end of the queue structure ( 1101 - 1104 in FIG. 7) with pointer operations.
- the queuing condition detection module 112 monitors conditions of the request queues 110 , 111 not only to select requests to be scheduled by the scheduler 104 , but also to extract information necessary to distribute appropriate resources to the respective services.
- the queuing condition detection module 112 is activated at fixed intervals by means of the transaction monitor 120 or the operating system on the server so as to perform predetermined processing.
- a sigalarm system call of the UNIX operating system can be used to activate the queuing condition detection module 112 at fixed intervals.
- FIG. 9 shows an example of a processing flow executed each time the queuing condition detection module 112 is activated.
- a request structure to be pointed from the request header are scaned ( 1302 ), and the number of requests in the queue is counted up ( 1303 ). Simultaneously, the oldest time stamp from among those of the request structures in the queue is selected.
- the number of request and the oldest time stamp are stored in the queuing information field ( 1118 in FIG. 7) of the request header.
- the scheduler 104 executes the scheduling of the requests on the basis of the information extracted by the queuing condition detection module 112 .
- the scheduling is so made that the requests with U.L. (upper limit) contract in the SLA class are given higher priority than those in the B.E. (best effort contract) class, and the requests in the B.E. class are scheduled only when there is room in the computer resources. In either class, the requests are scheduled sequentially from that with the oldest time stamp.
- U.L. upper limit
- B.E. best effort contract
- FIG. 10 shows a specific example of a processing flow for selecting requests to be scheduled.
- the scheduler 104 initializes all temporary variables ( 1401 ).
- “Tul” represents a temporary variable for storing the time stamp of each request belonging to the U.L. class service providers
- “Tbe” represents a temporary variable for storing the time stamp of each request in the B.E. class
- “Pul” and “Pbe” are temporary variables for storing pointers to the requests in the U.L. and B.E. classes, respectively.
- the scheduler 104 refers to the SLA information ( 1115 in FIG. 7) in the header to judge whether the header is in the U.L. or B.E. class ( 1403 ).
- the scheduler 104 compares the minimum time stamp previously stored as the temporary variable “Tul” with the oldest time stamp in the queue obtained from the queuing information ( 1118 in FIG. 7) stored in the request header ( 1404 ). If the time stamp concerned is older (smaller), the scheduler 104 replaces the temporary variable “Tul” ( 1405 ) and stores the pointer to the request header concerned as the temporary variable “Pul”.
- the scheduler 104 uses the temporary variables “Tbe” and “Pbe” to perform the same operations ( 1407 to 1409 ).
- the oldest time stamp and its associated request header can be obtained in both the U.L. and B.E. classes.
- the scheduler 104 determine which class, the U.L. or B.E. class, should be given preference on scheduling.
- the current time is time during the execution of the processing.
- the upper limit is the upper-limit time ( 804 in FIG. 3) of the service concerned under SLA contract defined in the SLA database 113 , and is obtained by referring to the SLA information in the request header ( 1115 in FIG. 7). Further, the symbol “e” represents an offset value decided by an operator of the transaction monitor 120 .
- the above-mentioned equation 1) is to check whether the request with the oldest time stamp in the U.L. class exists in a time slot (e) of the upper limit delay of the processing defined under SLA contract. If the request exists, the scheduler 104 gives a higher priority to the U.L. class to schedule the request in the U.L. class ( 1414 ). On the other hand, if no request exists in the time slot (e), since there is room to process the U.L. class, the request with the oldest time stamp in the B.E. class is scheduled ( 1415 ).
- the dynamic loader 105 receives the request scheduling results from the scheduler 104 to activate processes and load execution modules.
- the dynamic loader 105 contains therein process management information for managing conditions of processes to be activated in the service flow execution routine 107 .
- the process management information is used to manage which process corresponds to each service and which execution module is loaded for the process.
- a service structure has fields 1501 to 1503 one of which stores its service name.
- Such configured service structures 1521 , 1522 are linked as shown to create a service-specific list structure (service chain).
- Process structures 1531 , 1532 are pointed by respective process pointers 1502 from the service structures 1521 , 1522 , respectively.
- the process structures 1531 , 1532 each have four fields of process ID 1504 , pointer to execution module 1503 , flag 1504 indicative of whether the process is in use, and backward pointer 1505 .
- process structures 1531 , 1532 are linked as shown to form the list structure (process chain). Further, execution module structures 1541 - 1543 and 1551 - 1553 are pointed from the process structures 1531 and 1532 , respectively.
- the execution module structures each store module name 1508 , backward pointer 1509 and counter information 1510 indicative of the version of the execution module concerned.
- the execution module structures 1541 to 1543 (or 1551 to 1553 ) are linked as shown to form a list structure (module chain).
- the dynamic loader 105 traces the service chain ( 1521 , 1522 in FIG. 11) in the process management information to check whether a service to be scheduled exists in the chain ( 1602 ).
- the dynamic loader 105 traces the process chain ( 1531 , 1532 in FIG. 11) to search an unused process ( 1603 , 1604 ).
- the dynamic loader 105 shared-locks an execution module table 1700 in the execution module manager 106 to trace the module chain ( 1541 to 1543 in FIG. 11) constituting the process so as to check whether each module has been changed or updated since the previous loading ( 1607 , 1608 ).
- the dynamic loader 105 activates a new process to load a necessary execution module or modules ( 1621 ).
- the dynamic loader 105 first activates the process to register the ID in the process chain ( 1622 ). Then, for each column of the service flow definition table in the service flow definition module 115 ( 1623 ), the dynamic loader 105 judges whether each module belongs to the service to which the dynamic loader's attention is now directed ( 1624 ). If each module belongs to the service, the dynamic loader 105 loads the module ( 1625 ). It should be noted that the process ID may be a “pid” to be attached in the UNIX operating system.
- the execution module manager 106 manages addition, update and deletion of execution modules in the execution module library 116 .
- the execution module manager 106 has an execution module condition table as a data structure for holding or storing execution modules conditions.
- FIG. 13 shows an example of the execution module condition table.
- the update counter has an integer indicative of the number of updates of the execution module concerned.
- the update counter stores “1” at the time of registration of a new module, and increments the number by one each time the module is updated.
- the execution module condition table 1700 is accompanied with a lock field 1710 .
- the field stores a lock state of the table, taking three values N (unlocked), S (shared-locking) and E (exclusive locking).
- the dynamic loader 105 shared-locks the lock field of the execution module condition table 1700 ( 1606 in FIG. 12) to obtain, from a corresponding module structure (e.g., 1541 ), the name of the execution module to which the dynamic loader's attention is directed in the loop 1607 ( 1801 ).
- the dynamic loader 105 looks up the execution module condition table with the name ( 1802 ) to obtain a corresponding update counter ( 1803 ). Further, the dynamic loader 105 compares the counter value obtained with the value of a version counter ( 1510 in FIG. 11) in the module structure (e.g., 1541 ) ( 1804 ).
- the dynamic loader 105 determines that the execution module has not been changed since the previous loading to stop re-loading the execution module.
- the dynamic loader 105 determines that the execution module has been changed since the previous loading to re-load the execution module and substitute the value of the update counter into the version counter.
- the execution module manager 106 exclusively locks the lock field 1710 in the execution module condition table 1700 (“S”).
- the execution module manager 106 obtains from the transaction monitor 120 the name of execution module library to be updated.
- the name concerned can be obtained, for example, from information input by an operator from an operation console ( 720 in FIG. 2) of the transaction monitor. Then, the execution module manager 106 searches the execution module condition table 1700 to find a column having the same name as that of the module to be updated ( 1904 ) so as to increment the update counter in the column ( 1905 ). Finally, the execution module manager 106 releases the execution module condition table 1700 from exclusive locking (“N”)
- the request queues 110 , 111 are provided one for each service of each service provider registered in the transaction monitor 120 .
- the preprocessor 103 sends an input message to an appropriate request queues 110 or 111 on the basis of the contents of the message dictionary 114 .
- the queuing condition detection module 112 monitors conditions of the request queues 110 , 1111 to select requests to be scheduled by the scheduler 104 .
- the Scheduler 104 controls the requests on the basis of the information indicative of service priorities to plural service providers (customers) stored in the SLA database 113 (contract information related to service levels). Therefore, one transaction monitor 120 (or message broker) can be commonly used for plural customers while allocating each request to the optimum resource according to the predetermined priority or resource conditions, which makes it possible to guarantee proper throughput on any service.
- the transaction processing system can be used in a data center that performs contract outsourcing of plural service providers' systems and centralized control of computer resources. This makes possible real time processing of more on-line transactions with less computer resources with maintaining the throughput guaranteed under contract with the customers. Thus the reliability and performance of the data center that integrally processes business transactions for plural customers can be improved.
- the dynamic loader 105 that implements necessary processes for each of services provided by plural service providers collectively loads updated modules before transaction processing, the updated modules being judged by the execution module manager 106 that detects whether execution modules constituting each process are updated or not.
- Such a system makes it possible to change any service at any time when the transaction monitor 120 in operation without the need to provide means for disabling the routing of the execution modules or an auxiliary process group.
- Such a system can construct a transaction monitor 120 or message broker capable enhancing its flexibility and availability and making it easy to add and change business logic of customers with maintaining effective use of computer resources, which in turn makes the system operation easy.
- FIGS. 16 and 17 shows the second embodiment.
- the first embodiment assumed a particular case where there was in the service flow execution routine 107 a number of idling processes enough for the scheduler to schedule all the requests.
- this embodiment assumes a normal case where the number of processes may not be secured due to limited computer resources and some processes needs to be traded off between services.
- This embodiment is provided with a process manager 2001 instead of the scheduler 104 .
- the other elements are the same as those in the first embodiment.
- the process manager 2001 is operative to control the dynamic loader 105 by estimating the number of processes to be required for the processing concerned from service conditions of the request queues 110 , 111 and the SLA contract.
- each process After completion of a currently processed transaction, each process enters request acceptable state so that the next request can be extracted from a corresponding request queue 110 or 111 for the next transaction processing.
- the process manager 2001 Upon initiating the system, the process manager 2001 obtains the SLA conditions (in FIG. 3) related to each service from the SLA database 113 . The process manager 2001 periodically monitors the queue and process conditions when the system is in operation ( 2103 ) to perform the following operations.
- the process manager 2001 obtains the queuing information related to each service from the queuing condition detection module 112 ( 2102 ).
- the queuing information includes the number of waiting requests and the oldest time stamp.
- the queuing information can be obtained by referring to the queuing information field 1118 of the request header extracted by the queuing condition detection module 112 .
- the process manager 2001 obtains, from the service flow execution routine, the transaction starting time and finishing time and the number of processes corresponding to the service to calculate throughput to the transaction.
- the total throughput to the service concerned is determined by the sum of reciprocal numbers of time periods required for the transactions processed by the respective processes.
- the process manager 2001 determines, from the queuing information obtained, a difference between the previous queuing length and the current queuing length (the number of waiting requests in the queue) to calculate the frequency of arrival of requests.
- the frequency of arrival of requests can be calculated by dividing the difference in the queuing length by the time interval.
- the process manager 2001 may obtain a difference between the start time and stop time of each transaction to determine throughput to the transaction by multiplying the reciprocal number of the difference by the number of processes to be allocated for the service.
- the queuing length is considered to be reduced with time. If it is smaller, the queuing length is considered to increase with time.
- the level of satisfactory throughput is determined by dividing the total throughput by the frequency of arrival of requests ( 2109 ).
- the process manager 2001 After completion of determining the level of satisfactory throughput to each service, the process manager 2001 changes the number of processes for the service to control the processes so that the optimum throughput will be distributed to each service.
- the process manager 2001 newly calculates the number of processes needed to set the level of satisfactory throughput to one or more in the order of priority decided according to the SLA contract ( 2108 ). If the number of processes newly calculated is larger than the number of process currently existed, the process manager 2001 activates a number of processes corresponding to the difference between the newly calculated number and the existing number, and loads necessary execution modules through the dynamic loader 105 with keeping the loaded execution modules waiting ( 2112 ).
- Such a scheduling technique allows processes to be distributed to services having higher priorities in terms of SLA contract, which increase the probability of success in satisfying each service contract. At the same time, if there is room in the level of satisfactory throughput, affordable resources can also be allocated to such services that their priorities are low.
- control can be carried out by taking into account histories of processes such as to prohibit the processes once activated from being stopped during a fixed time period.
- the operations in FIG. 17 may keep low-priority requests waiting a long time.
- the minimum number of processes for each service has only to be determined beforehand so that the number of processes can be increased or decreased in such a range that the number of processes is never below the predetermined number.
- Another feature of the second embodiment is transaction processing capable of providing one or more services and connecting one or more clients to each service.
- This feature is implemented by queuing means ( 110 , 111 ) for storing processing requests from the clients for services while assigning priorities to the requests for each service, waiting condition obtaining means (queuing condition detection module 112 ) for obtaining waiting conditions of processing requests stored in the queuing means, and process allocating means (process manager 2001 ) for allocating processing processes of transactions to each service.
- the process allocating means decides the allocation of processes to each service by referring to the process request waiting conditions obtained and throughput to each transaction.
- a program for allocating processes is carried out by comparing the frequency of arrival of processing requests in a unit time, calculated from the processing request waiting conditions, with the throughput to the transaction. If the frequency of arrival of processing requests is larger than the throughput to the transaction, the number of processes to be allocated is increased. On the other hand, if the frequency of arrival of processing requests is smaller than the throughput to the transaction, the number of processes to be allocated is reduced.
Abstract
There is provided a transaction processing system for providing plural services according to service level contracts, the system comprising: an SLA database for storing contract conditions defined for each of the services provided; request queues for storing processing requests sent from clients for the services provided while putting the respective services into a particular order; queuing condition detection module for obtaining waiting conditions of the processing requests stored in the request queues; and a scheduler for deciding priorities to the processing requests input from the client to the transaction processing system by referring to the contract conditions and the waiting conditions of the processing requests.
Description
- 1. Field of the Invention
- The present invention relates to a transaction processing system, and in particular to implementation of transaction processing in response to requests from plural customers.
- 2. Description of the Related Art
- The transaction system is a system for efficiently executing a lot of processing requests in such a manner as to assure consistency in a basic line of corporate information system such as financial trading and ordering/order receiving. In general, a client/server system is so constructed that a client (terminal) issues a request and a server executes the main body of transaction processing by accessing a database as required. A processing program executing an actual transaction on the server is called service.
- The service providing side in the transaction system is called a service provider. For example, in the retailing bank business, ATMs or tellers are clients, and the basic system including a customer's account database is a server. In this case, the bank is the service provider, which provides services such as withdrawal and deposit transactions.
- Transaction processing middleware used on the server side is a transaction monitor. The transaction monitor mainly takes the following two parts.
- (1) The transaction monitor receives processing requests sent from clients and queues the processing requests by taking into account request priorities and crowding levels on the server to forward control of the respective requests to appropriate server programs (service) one by one, thus making effective use of server resources.
- (2) The transaction monitor detects errors or faults caused during execution of processing. If the processing has completed successfully, it carries out result writing (committing) operation, while if the processing has not completed successfully, it carries out cancel (rollback) or re-run operation. Thus the transaction monitor assures consistency of the transaction processing.
- FIG. 18 shows a typical configuration of the transaction monitor.
- As shown, a
transaction monitor 209 is located on aserver 215, whileclient programs client terminals - In general, the
server 215 is a UNIX server, a mainframe computer or the like, while the client terminal is a personal computer, an ATM terminal or the like. - The
transaction monitor 209 includesrequest queues scheduler 204 and atransaction execution module 207. - The processing request for a service is typically transferred from the
client server 215 in the form of a message (electronic text). Therefore, the transaction monitor has a communication function module so that the transaction monitor receives a processing message by controlling its own communication function module. - The message received is stored in the
transaction monitor 209 as a processing request. Since two or more requests are usually kept waiting in thetransaction monitor 209, thetransaction monitor 209 uses thequeues queues transaction execution module 207 becomes available, and processed bycorresponding service programs 206. - (Scheduling and Load Balancing)
- Scheduling is to extract a request from a queue and move the request to the execution of service program processing for the request. Efficient scheduling is necessary to increase the efficiency of the transaction processing system.
- In particular, if there exist plural resources (processor, server etc.) that provide services, processing efficiency depends a lot on how to allocate the requests to the plural resources. Allocating requests to the plural resources to increase the efficiency of transaction processing is called load balancing. Thereinafter, including both the scheduling above-mentioned and load balancing operations, the entire allocating process of the requests to the resources may be referred as “scheduling,”.
- As one approach to scheduling, a method of balancing load by increasing or decreasing the number of processes for providing a service is known. An outline of the method will be described with reference to FIG. 19.
- In FIG. 19,
requests 301 to 309 are stored in arequest queue 300. These requests are supposed to be processed byprocesses 310 to 313 one by one. The term “process” is a unit of program to be processed on a computer, and the unit is a combination of one virtual address space, a program loaded on the space, data and a CPU register indicative of an execution state of the program. - In the example of FIG. 19, the same transaction processing program (service program) is loaded in all the processes. If free spaces are available in the CPU of the computer, the number of services to be provided concurrently is increased by increasing the number of processes so that the utilization factor of the CPU can be improved.
- In other words, increasing or decreasing the number of processes allocated to transactions make it possible to control processing throughput to the transactions (the number of requests to be processed in a unit time).
- FIG. 19A shows a case where a very small number of requests are stored in the
queue 300. In this case, the transaction monitor allocates a small number of processes (310, 311) to the service concerned according to the number of requests. - FIG. 19B shows a case where a large number of requests arrive and hence the number of requests queued in the
queue 300 increases. In this case, the transaction monitor monitors conditions in the queue to increase the number of processes to be allocated to the service (310 to 313). - FIG. 19C shows a case where incoming messages are reduced and the length of the queue becomes short. In this case, the transaction monitor deallocates the
idling process 313 from the service and allocate it to another service or task. By associating the length of the queue with the number of processes to be allocated, it becomes possible to improve transaction efficiency within a range of CPU resources. - And, in case that there are plural servers to be controlled by the transaction monitor, a system shown in FIG. 20 is used for balancing load among servers.
- Suppose that there are three servers (420 to 422), and that a
queue 400 of one of the servers (server 420) becomes longer than theother queues processing program 431 on the client side detects this state and controls itself to send messages by priority toshorter queue server - (Message Broker)
- Example applications of the transaction monitor for a further advanced multi-transaction processing system include a message broker.
- A normal transaction processing system has a one-to-one correspondence between a message and a service, but a message broker performs processing by passing one message among plural services by recursively invoking. The message broker stores in the transaction monitor a service flow (business flow), which designates what services and in what sequence the services are invoked for the message. The services to be invoked may be located on the same server as the transaction monitor or another independent stand-along server.
- FIG. 21 shows a configuration of the message broker.
-
Client programs transaction monitor 509 is located on a transaction processing server. - Service programs A530 and B531 for providing business services are loaded on different servers (or the same server). The terminals and the servers are connected with each other through message communications lines. The transaction monitor 509 includes
request queues scheduler 504 for deciding the sequence of request processing. - Compared to the normal transaction processing system (FIG. 18), the message broker adds an extension to the transaction execution module (207 in FIG. 18) to constitute a service
flow execution routine 507. - The service
flow execution routine 507 manages the execution of a service flow defined by the service provider, not just initiate and execute a service program according to a message. - Since the message broker allows the execution of a service flow on the transaction monitor, it can combine plural service programs to construct more complicated service structure.
- (Node Replacement During Operation)
- In the message broker the service flow may often be altered or changed due to an update or addition of business service. It is undesirable to stop the entire system each time the service flow is altered or changed. For this reason, a mechanism for changing only the service flow without stopping the system operation is highly required.
- One method is to divide the processes executing the service flow into two groups (active group and standby group). In this case, the active group executes the unchanged flow while re-loading a new service flow to the standby group. Upon completion of loading, message routing is switched from the active group to the standby group in the continuation of the system's operation.
- Another method is to provide routing enable and disable modes for each service node. In this case, a node to be replaced is changed to routing disable mode, thereby prohibiting input of any message to the node upon re-loading of a new service flow to the node.
- The above-mentioned transaction or message broker processing systems are known from the following publications: Japanese Patent Laid-Open Application No. 09-062624 (JP-A-09-062624) (Processing System for On-line Transaction); Japanese Patent Laid-Open Application No. 06-243077 (JP-A-06-243077) (Distributed Transaction Processing System); Japanese Patent Laid-Open Application No. 08-063432 (JP-A-08-063432) (Transaction Batch Processing System in Consideration of Priority); Japanese Patent Laid-Open Application No. 06-052121 (JP-A-06-052121) (Batch processing-Real Time Processing Sorting Type Transaction Processing System); Japanese Patent Laid-Open Application No. 07-073143 (JP-A-07-073143) (Time Band-Based Priority Control Transaction Processing System); and Japanese Patent Laid-Open Application No. 10-040117 (JP-A-10-040117) (Task Control type On-line Transaction Processing System for Maintaining High Response).
- New business activities such as in a data center, which perform contract outsourcing of systems of plural service providers (or customers) and centralized control of computer resources to improve the total processing efficiency, is growing steadily.
- Such a data center is operated under service level agreements (SLA) with service providers to bill the service providers according to the computer resources used (the amount of transaction, associated CPU operating time, data amount, etc.) and service guaranty conditions. To reduce the billing, it is necessary to execute more transactions with fewer computer resources (investment).
- In contrast, the above-mentioned conventional transaction processing systems using a transaction monitor or message broker are constructed on assumption that a single service provider provides services to its clients alone. Therefore, these conventional systems do not allow for common use of one transaction processing system among plural service providers, and hence coordination of transaction resources (computer resources) and amounts of throughput among the plural service providers.
- In other words, upon receiving transaction processing requests from plural clients, the conventional systems cannot make effective use of computer resources, which makes it difficult to secure a sufficient amount of throughput for each client.
- Further, the above-mentioned conventional message broker or transaction monitor needs to be provided with an auxiliary process group or routing closing means for updating the service flow due to an update or addition of business services. In other words, the conventional message broker or transaction monitor does not allow for effective use of computer resources among plural clients, which makes flexible operation difficult.
- It is therefore an object of the present invention to realize a transaction processing system suitable for providing business services to plural service providers by enabling transaction priority control and allocation control of computer resources in consideration of the above-mentioned SLA.
- A representative mode to be disclosed in this specification is a transaction processing system comprising: means for holding or storing priority conditions defined according to services the transaction processing system provides; queuing means for storing processing requests sent from clients for the services while putting the respective services into a particular order; means for obtaining waiting conditions of the stored process requests from the queuing means; and means of execution prioritization for deciding execution priorities to the processing requests input from the clients to the transaction processing system by referring to the priority conditions and the waiting conditions of the processing requests.
- It is preferable that the queuing means is provided with plural queues each of which can store processing requests from each customer or user to which corresponding service is provided. It is also preferable that the means for storing priority conditions contains priority conditions defined according to the type of processing (service to be executed) and the customer or user.
- Specifically, the transaction processing system further comprises means for detecting throughput to a transaction to control the allocation of computer resources to each service, and means for allocating transaction processing processes to the service, wherein the means for allocating processes decides the allocation of processes to the service by referring to the process request waiting conditions obtained and the transaction throughput detected.
- More specifically, the transaction processing system further comprises means for storing an identifier or identifiers of one or more execution modules constituting each service, and means for managing an update of each execution module on the basis of the identifier, whereby when the update managing means executes the update of the execution module, the updated execution module is placed (loaded) to storage means prior to starting the transaction corresponding to the service.
- As discussed above and according to the present invention, the transaction processing system or message broker carries out priority control to each service in consideration of priority conditions defined according to the services the transaction processing system provides, and processing request waiting conditions obtained from the queuing means for storing processing requests sent from clients for the services while putting the respective services into a particular order.
- The above configuration makes possible transaction scheduling which meets the contract conditions for each service the transaction processing system provides for each customer, and hence real time processing of more on-line transactions with less computer resources with maintaining the throughput guaranteed under contract with the customer. Thus the reliability and performance of the data center that integrally processes business transactions for plural customers can be improved.
- According to the present invention, the transaction processing system further comprises means for detecting throughput to a transaction corresponding to each service, and means for allocating a transaction processing processes to the service, wherein the means for allocating the processes decides the allocation of processes to the service by referring to the process request waiting conditions obtained and the transaction throughput detected.
- The above-mentioned configuration makes possible the allocation of such processes as to meet the contract conditions for each service the transaction processing system provides for each customer, and hence real time processing with maintaining the throughput guaranteed under contract with the customer. Thus the reliability and performance of the data center that integrally processes business transactions for plural customers can be improved.
- According to the present invention, the transaction processing system further comprises means for storing an identifier or identifiers of one or more execution modules constituting each service, and means for managing an update of each execution module on the basis of the identifier, wherein when the execution module or modules have been updated by the update managing means, the updated execution module or modules are placed in the storage means prior to starting the transaction corresponding to the service.
- In the above-mentioned configuration, when the execution module or modules have been updated by the update managing means, the updated execution module or modules are placed in the storage means prior to starting the transaction corresponding to the service, which makes possible an update or addition of business services with maintaining the system operation. Thus the flexibility and availability of the transaction processing system can be improved. Further, since any auxiliary process group or routing closing means does not need to be provided for updating the execution modules, effective use of computer resources can be realized.
- FIG. 1 is a block diagram showing a general structure of one preferred embodiment according to the present invention.
- FIG. 2 is a block diagram showing a hardware structure of the embodiment according to the present invention.
- FIG. 3 is a table showing an SLA database.
- FIGS. 4A to4D are tables showing a message dictionary, in which
- FIG. 4A shows a fixed part definition module and
- FIGS. 4B to4D show variable part definition modules.
- FIGS. 5A and 5B are descriptive diagrams of a service flow, in which
- FIG. 5A shows a relationship between node and service program, and
- FIG. 5B shows a relationship among node name, node type, input source, output destination and module.
- FIG. 6 is a diagram showing data structure of a message.
- FIG. 7 is a diagram for explaining a configuration of a request queue.
- FIG. 8 is a PAD diagram showing operations of the request queue.
- FIG. 9 is a PAD diagram showing operations of a queuing condition detection module.
- FIG. 10 is a PAD diagram showing operations of a scheduler.
- FIG. 11 is a diagram showing a configuration of process management information.
- FIG. 12 is a PAD diagram showing operations of a dynamic loader.
- FIG. 13 is a diagram showing a configuration of an execution module condition table.
- FIG. 14 is a PAD diagram showing detailed operations of the dynamic loader.
- FIG. 15 is a PAD diagram showing operations of an execution module manager.
- FIG. 16 is a block diagram showing a second embodiment according to the present invention.
- FIG. 17 is a PAD diagram showing operations of a process management module according to the second embodiment of the present invention.
- FIG. 18 is a block diagram showing a conventional transaction processing system.
- FIGS. 19A to19C are diagrams showing conventional process number control, in which
- FIG. 19A is a case where there exists one request,
- FIG. 19B is a case where many requests are waiting, and
- FIG. 19C is a case where the requests are reduced.
- FIG. 20 is a diagram showing conventional priority control.
- FIG. 21 is a block diagram showing a conventional message broker.
- Hereinbelow, one preferred embodiment of the present invention will be described with reference to the accompanying drawings.
- 1. Hardware Structure
- FIG. 2 shows a hardware structure of a computer system according to one preferred embodiment of the present invention. The system is constructed of one or
more client terminals more transaction servers 703, and one or more serviceprogram executing servers - The
client terminals - The
transaction processing server 703 and the serviceprogram executing servers Communication lines 710 connecting the clients and each server are, for example, general-purpose networks such as the Ethernet. It should be noted that thetransaction processing server 703 and the serviceprogram executing servers - 2. General Structure of the Embodiment
- Referring to FIG. 1, description will be made first about a general structure of the embodiment before detailed description of the embodiment.
-
Client programs client terminals specific client terminal transaction processing server 703. - The above-mentioned client programs correspond to ATM control programs or client programs for personal computers. The client programs may be Web browsers. Each client program builds up a message in response to input from an end user to send the message to a
transaction monitor 120. - The transaction monitor120 is a key feature of the embodiment. Unlike the
conventional transaction monitor 120, the transaction monitor 120 of the embodiment can receive messages (processing requests) to plural service providers (hereinafter, also referred to as customers). It is assumed in FIG. 1 that the number of service providers is two. - An SLA database (priority condition database)113 stores contract conditions (SLA) related to service levels (priority conditions, allowable waiting time) under contract with each service provider. For example, based on such contract contents that “transactions for service provider A should be processed in 10 seconds or less,” an allowable waiting time of 10 msec. and priority U.L may be stored in the database.
- A format of messages from each service provider is defined in a
message dictionary 114. For example, such a definition that “10th to 20th bytes in a message from service provider A describe customer account number” may be stored. - Definitions of a service flow for each service provider are stored in a service
flow definition module 115. A group of execution modules corresponding to respective service nodes of the service flow are stored in an executingmodule library 116. - A
preprocessor 103 interprets a message from theclient server - Each of
request queues transaction monitor 120; it stores requests sent to the service provider. Since it is assumed in FIG. 1 that the number of service providers is two, there exist tworequest queues - A queuing
condition detection module 112 monitors therequest queues - A
scheduler 104 decides scheduling priority in consideration of queuing conditions obtained from the queuingcondition detection module 112 and the SLA contract conditions stored in theSLA database 113. Thescheduler 104 also manages the number ofprocesses - The messages taken up by the
scheduler 104 are sent to adynamic loader 105. - The
dynamic loader 105 decides a service flow corresponding to the current message by referring to the serviceflow definition module 115. - An
execution module manager 106 monitors the executingmodule library 116 to detect an update if any. Thedynamic loader 105 refers to the detection results to judge whether service nodes needed for execution of a service corresponding to the current message have been already loaded in the current process. If not loaded (or old modules remain loaded), a new group of modules are loaded. Then a serviceflow execution routine 107 executes the service flow scheduled. - Hereinbelow, description will be made in detail about each element constituting the system according to the embodiment of the present invention.
- 3. SLA Database
- Referring to FIG. 3, an exemplary configuration of the
SLA database 113 will be described. - The
SLA database 113 is stored on a disk in the form of a table. A data center operating thetransaction monitor 120 accumulates contract contents under contract with customers (service providers) in theSLA database 113. - The first row in the table contains column heads of Service Provider's
Name 801, Service Name (Processing Type) 802,Class 803,Upper Limit 804 andPriority 805. - The column below Service Provider's
Name 801 lists names of service providers as processing contract targets of the transaction monitor. This column may contain any character string as long as it is a unique name. - The column below
Service Name 802 lists names of services provided by the corresponding service providers through the transaction monitor. The column belowClass 803 represents types of contracts with the respective service providers, where “B.E.” stands for “Best Effort” to indicate such a contract item that the transaction should be scheduled as long as resources are available. In this case, if the resources are crowded with other transactions, the transaction might be kept waiting a long time. On the other hand, “U.L.” stands for “Upper Limit” to indicate a contract item which decides on the upper limit of transaction waiting time. - The column below
Upper Limit 804 represents upper limit times under the “U.L.” contract. If the corresponding service provider has a contract for “B.E.”, the column does not make sense. - The column below
Priority 805 represents priorities to services under the “U.L.” contract. If the resources are so crowded that the “U.L.” contract cannot be satisfied, scheduling of services is carried out in order of precedence. It should be noted thatPriority 805 may be decided according to the contact with each service provider or the data center side may independently assign priorities to service providers as customers or to services. - FIG. 3 shows a basic structure of the SLA database. In addition to the basic structure, the data center can independently set other items, for example, such as priority according to processing load on each service.
- Thus, priority and upper limit (allowable waiting time) are defined for each service (each customer, where processing=type of service flow) in the SLA database (means for storing priority conditions). These definitions are set and stored by an operator through input means, not shown. The
preprocessor 103 and thescheduler 104 refers to the priority conditions stored in theSLA database 113. The scheduler 104 (means of execution prioritization) searches theSLA database 113 for a service provider's name and service name on the basis of service identification information as search criteria in a manner to be described later to read in the priority conditions. - 4. Message Dictionary
- Referring to FIGS. 4A to4D and FIG. 6, an exemplary configuration of the
message dictionary 114 will be described. Themessage dictionary 114 stores definitions of a message format for each service provider and each service. - Each of messages the
transaction monitor 120 receives is composed of a fixed part (1001, 1002 in FIG. 6) and a variable part (1003 in FIG. 6). The fixed part contains message fields unique to the transaction monitor 120 while the variable part contains a message field varied by each service provider and each service. - Corresponding to the message structure of FIG. 6, the
message dictionary 114 also contains a fixed part definition module (FIG. 4A) and variable part definition modules (FIGS. 4B, 4C and 4D). - In the example of FIG. 4A, the fixed part definition module has columns of Starting Byte (901), Length (902) and Type (903), indicating that the service provider's name is stored in a 32-byte field from zero byte, and the service name is stored in a 32-byte field from the 32nd byte. The 64th byte and the following bytes belong to the variable part.
- The variable part definitions are made by combining a variable-part index definition module (FIG. 4B) with variable-part field definition modules (FIGS. 4C and 4D).
- The variable-part index definition module is formed into a table for use in searching indexes of the variable-part field definition modules on the basis of the service provider's
name 905 and the service name 906 (service identification information) entered in thefields - The variable-part field definition module (FIG. 4C) having the same table index (=“1”) represents definitions related to “service A1.” Similarly, the index for “service A2” of “service provider A” is “2.” The variable-part field definition module (FIG. 4D) having the same table index represents definitions related to “service A2.”
- Each table index sets fields of Starting Byte, Length and Data Type. FIG. 4C shows that the account number is stored in a four-byte field from the 64th byte, the time stamp is stored in a 12-byte field from the 68th byte, and the withdrawal amount is stored in an 8-byte field from the 80th byte. FIG. 4D also shows the same except that the 8-byte field from the 80th byte corresponds to the current balance.
- Upon inputting a message to the
transaction monitor 120, the definition modules allow the transaction monitor 120 to judge, from the fixedpart variable part 1003 of the message, parameters of the service can be set. - 5. Service Flow Definition Module and Service Flow Execution Routine
- As shown in FIG. 5, the service
flow execution routine 107 is formed by connecting individual processes on the basis of the message entered. Combining plural processes (processing nodes), each of which has its own purpose, makes it possible to realize a complicated function. - FIG. 5A shows a service flow consisting of five
processing nodes 601 to 605, in which arrows indicate a flow of the message between nodes. - The
node 601 receives the message from a terminal via the transaction monitor, and forwards the message to theprocessing node 602. Theprocessing node 602 refers to the message to perform processing defined by the user while modifying the message if required, and forwards the message to thedownstream nodes - The
node 603 is a message conversion node that performs code conversion of the message according to the coding format of a service program on the output destination side (for example, it performs conversion from EBCDIC code to ASCII code). Thenodes - FIG. 5B shows information on the service
flow definition module 115. -
Columns 620 to 624 represent definition conditions for thenodes 601 to 605, respectively. The service name specifies a service name to which each node belongs. The node name specifies any node name in such a manner that the node name is determinately defined in the flow. The node type selects and specifies an appropriate one of the node types provided in the message broker system from among the node types, such as input node, processing node, conversion node and output node. The input source and the output destination specify a node name as input source and output destination to and from the node specified in the corresponding “Node Name” column. For example, thenode B 602 receives the message from thenode A 601, and output the message to thenode C 603 and thenode E 605. Further, the processing node and the conversion node have individual processing contents specified. - The specification of the processing contents is made possible by storing corresponding processing modules in the bottommost “Module” columns of the
definition conditions 620 to 624. Since the other nodes such as the input/output nodes perform routine processing and use predetermined regular modules, their processing names do not need specifying. - The service
flow definition module 115 and the serviceflow execution routine 107 allow the execution of the service flow on the transaction monitor, which in turn makes it possible to construct a message broker capable of providing more complicated services by combining plural service programs. - 6. Executing Module Library
- The executing
module library 116 stores execution module groups needed for executing each service node in the service flow. Each execution module can be stored, for example, in the UNIX file format. The file name is made correspondent with the module name appearing in the service flow definition module, which makes it possible to retrieve a corresponding execution module from the service flow. - The execution module is created in such a format that it can be dynamically loaded during execution, for example, in the UNIX DLL (Dynamic Loading Library) format.
- 7. Request Queue
- The
request queues - The
request queues transaction monitor 120. FIG. 7 shows the structure of each request queue. - In FIG. 7, the request queue is constituted of a
request header 1114 to 1116 provided one for each queue, andplural request structures 1101 to 1104 connected from the request header in a list structure. - The request header contains fields of
service information 1114,SLA information 1115,backward chain 1116, queuing top pointer or startaddress 1117 and queuinginformation 1118. - The
service information field 1114 is for storing a service provider and service name allocated to the queue. TheSLA information field 1115 is for storing an SLA definition module stored in theSLA database 113. The SLA definition module is retrieved from theSLA database 113 on the basis of the service provider and service name and stored in the request header. - The
backward chain field 1116 is for storing pointers to connect the request header with the other request headers in a list structure in case of the presence of plural queues. FIG. 7 shows such condition thatplural request headers 1130 to 1132 are connected using backward pointers. - The queuing top pointer or start address field117 is for storing a pointer or start address to the top request structure of each queue (first created request structure in each queue). The queuing
information field 1118 is for storing request conditions queued in each queue. Directions for use of the queuing information 118 will be described later. - Each request structure contains four
fields 1110 to 1113. Thetime stamp field 1110 indicates the time of creation of each request. The forward andbackward chain fields message pointer field 1115 stores a pointer or address to an area in which the message main body is stored. -
Chains 1101 to 1104 show such condition that the request structures form a queue in forward and backward chains.Message storage areas 1120 to 1123 correspond to respective requests, and pointed by each message pointer stored in the corresponding request structure. - 8. Preprocessor
- The
preprocessor 103 compares a message input to the transaction monitor with the contents of themessage dictionary 114 to analyze which service provider and which service the message belong to. As a result of the analysis, the message is stored in anappropriate request queue - FIG. 8 shows an example of an operation flow of the preprocessor.
- Upon activation, the
preprocessor 103 reads information on the message fixed part (1001, 1002 in FIG. 6) from the message dictionary 114 (1201). - Then, the
preprocessor 103 enters aloop 1202 to receive messages from clients until the transaction monitor 120 finishes providing services, and becomes a message input waiting state (1203). After completion of providing all the services, thepreprocessor 103 may exit from theloop 1202 or perform interrupt processing to break the loop. - The message input waiting state can be realized, for example, by the UNIX accept system call. Upon receipt of a message, the
preprocessor 103 uses the message fixed-part information already read in thestep 1201 to extract service provider's name and service name corresponding to the message (1204). - Next, the
preprocessor 103 searches the request headers one by one (1205) to retrieve a queue corresponding to the service provider's name and service name obtained (1206) so as to resister the message (electronic text) input to the queue. The registration of the message can be carried out-such that a new request structure (1110-1113 in FIG. 7) containing the message, the service provider's name and the service name is created, and put at the tail end of the queue structure (1101-1104 in FIG. 7) with pointer operations. - 9. Queuing Condition Detection Module
- The queuing
condition detection module 112 monitors conditions of therequest queues scheduler 104, but also to extract information necessary to distribute appropriate resources to the respective services. - The queuing
condition detection module 112 is activated at fixed intervals by means of the transaction monitor 120 or the operating system on the server so as to perform predetermined processing. Here, a sigalarm system call of the UNIX operating system can be used to activate the queuingcondition detection module 112 at fixed intervals. - FIG. 9 shows an example of a processing flow executed each time the queuing
condition detection module 112 is activated. - For each request header (1301), a request structure to be pointed from the request header are scaned (1302), and the number of requests in the queue is counted up (1303). Simultaneously, the oldest time stamp from among those of the request structures in the queue is selected.
- The number of request and the oldest time stamp are stored in the queuing information field (1118 in FIG. 7) of the request header.
- 10. Scheduler
- The
scheduler 104 executes the scheduling of the requests on the basis of the information extracted by the queuingcondition detection module 112. - The scheduling is so made that the requests with U.L. (upper limit) contract in the SLA class are given higher priority than those in the B.E. (best effort contract) class, and the requests in the B.E. class are scheduled only when there is room in the computer resources. In either class, the requests are scheduled sequentially from that with the oldest time stamp.
- FIG. 10 shows a specific example of a processing flow for selecting requests to be scheduled.
- First of all, the
scheduler 104 initializes all temporary variables (1401). Instep 1401, “Tul” represents a temporary variable for storing the time stamp of each request belonging to the U.L. class service providers, “Tbe” represents a temporary variable for storing the time stamp of each request in the B.E. class, and “Pul” and “Pbe” are temporary variables for storing pointers to the requests in the U.L. and B.E. classes, respectively. - Next, for each header (1402) stored in the request header lists (1130 to 1132 in FIG. 7), the
scheduler 104 refers to the SLA information (1115 in FIG. 7) in the header to judge whether the header is in the U.L. or B.E. class (1403). - If the header is in the U.L. class, the
scheduler 104 compares the minimum time stamp previously stored as the temporary variable “Tul” with the oldest time stamp in the queue obtained from the queuing information (1118 in FIG. 7) stored in the request header (1404). If the time stamp concerned is older (smaller), thescheduler 104 replaces the temporary variable “Tul” (1405) and stores the pointer to the request header concerned as the temporary variable “Pul”. - On the other hand, if it is judged in the above-mentioned
judgment step 1403 that the header concerned belongs to the B.E. class, thescheduler 104 uses the temporary variables “Tbe” and “Pbe” to perform the same operations (1407 to 1409). As a result of the above-mentioned processing flow, the oldest time stamp and its associated request header can be obtained in both the U.L. and B.E. classes. - Next, the
scheduler 104 determine which class, the U.L. or B.E. class, should be given preference on scheduling. - First, if either “Pul” or “Pbe” is Null, the
scheduler 104 schedules the request not having Null (1410 to 1412). - If both are not Null, the
scheduler 104 evaluates both requests form the following equation 1): - Tul<((current time−upper limit)+e) 1)
- In the equation 1), the current time is time during the execution of the processing. The upper limit is the upper-limit time (804 in FIG. 3) of the service concerned under SLA contract defined in the
SLA database 113, and is obtained by referring to the SLA information in the request header (1115 in FIG. 7). Further, the symbol “e” represents an offset value decided by an operator of thetransaction monitor 120. - The above-mentioned equation 1) is to check whether the request with the oldest time stamp in the U.L. class exists in a time slot (e) of the upper limit delay of the processing defined under SLA contract. If the request exists, the
scheduler 104 gives a higher priority to the U.L. class to schedule the request in the U.L. class (1414). On the other hand, if no request exists in the time slot (e), since there is room to process the U.L. class, the request with the oldest time stamp in the B.E. class is scheduled (1415). - 11. Dynamic Loader
- The
dynamic loader 105 receives the request scheduling results from thescheduler 104 to activate processes and load execution modules. - The
dynamic loader 105 contains therein process management information for managing conditions of processes to be activated in the serviceflow execution routine 107. - Referring to FIG. 11, an exemplary structure of the process management information will be described.
- The process management information is used to manage which process corresponds to each service and which execution module is loaded for the process.
- A service structure has
fields 1501 to 1503 one of which stores its service name. Such configuredservice structures -
Process structures respective process pointers 1502 from theservice structures - The
process structures process ID 1504, pointer toexecution module 1503,flag 1504 indicative of whether the process is in use, andbackward pointer 1505. - The
process structures process structures - The execution module structures each
store module name 1508,backward pointer 1509 andcounter information 1510 indicative of the version of the execution module concerned. Theexecution module structures 1541 to 1543 (or 1551 to 1553) are linked as shown to form a list structure (module chain). - Referring next to FIG. 12, a processing flow of the dynamic loader will be described.
- First of all, the
dynamic loader 105 traces the service chain (1521, 1522 in FIG. 11) in the process management information to check whether a service to be scheduled exists in the chain (1602). - If such a service exists, since at least one process has been already activated for processing the service, the
dynamic loader 105 traces the process chain (1531, 1532 in FIG. 11) to search an unused process (1603, 1604). - If an unused process exists, the
dynamic loader 105 shared-locks an execution module table 1700 in theexecution module manager 106 to trace the module chain (1541 to 1543 in FIG. 11) constituting the process so as to check whether each module has been changed or updated since the previous loading (1607, 1608). - The details of the
execution module manager 106 and the execution module management table 1700 will be described later. If a change is detected, the module concerned is loaded (1609). - On the other hand, if no service to be scheduled exists in the chain (1605), or if no unused process exists in the process chain (1606), the
dynamic loader 105 activates a new process to load a necessary execution module or modules (1621). - In this processing, the
dynamic loader 105 first activates the process to register the ID in the process chain (1622). Then, for each column of the service flow definition table in the service flow definition module 115 (1623), thedynamic loader 105 judges whether each module belongs to the service to which the dynamic loader's attention is now directed (1624). If each module belongs to the service, thedynamic loader 105 loads the module (1625). It should be noted that the process ID may be a “pid” to be attached in the UNIX operating system. - 12. Execution Module Manager
- The
execution module manager 106 manages addition, update and deletion of execution modules in theexecution module library 116. Theexecution module manager 106 has an execution module condition table as a data structure for holding or storing execution modules conditions. - FIG. 13 shows an example of the execution module condition table.
- Columns below
heads 1701 to 1705 of the condition table 1700 correspond to respective execution modules stored in theexecution module library 116. For each execution module, execution module name and update counter information (identifier) are stored. - The update counter has an integer indicative of the number of updates of the execution module concerned. The update counter stores “1” at the time of registration of a new module, and increments the number by one each time the module is updated.
- The execution module condition table1700 is accompanied with a
lock field 1710. The field stores a lock state of the table, taking three values N (unlocked), S (shared-locking) and E (exclusive locking). - Referring next to FIG. 14, description will be made in detail about a step (1608 in FIG. 12) in which the
dynamic loader 105 detects update conditions of the execution module using the condition table. - First of all, the
dynamic loader 105 shared-locks the lock field of the execution module condition table 1700 (1606 in FIG. 12) to obtain, from a corresponding module structure (e.g., 1541), the name of the execution module to which the dynamic loader's attention is directed in the loop 1607 (1801). - Next, the
dynamic loader 105 looks up the execution module condition table with the name (1802) to obtain a corresponding update counter (1803). Further, thedynamic loader 105 compares the counter value obtained with the value of a version counter (1510 in FIG. 11) in the module structure (e.g., 1541) (1804). - If the value of the update counter is equivalent to that of the version counter, the
dynamic loader 105 determines that the execution module has not been changed since the previous loading to stop re-loading the execution module. - On the other hand, if the value of the update counter is larger than that of the version counter, the
dynamic loader 105 determines that the execution module has been changed since the previous loading to re-load the execution module and substitute the value of the update counter into the version counter. - Referring next to FIG. 15, description will be made below about a processing flow of the
execution module manager 106 upon updating modules in the execution module library. - First of all, the
execution module manager 106 exclusively locks thelock field 1710 in the execution module condition table 1700 (“S”). - Then, the
execution module manager 106 obtains from the transaction monitor 120 the name of execution module library to be updated. - The name concerned can be obtained, for example, from information input by an operator from an operation console (720 in FIG. 2) of the transaction monitor. Then, the
execution module manager 106 searches the execution module condition table 1700 to find a column having the same name as that of the module to be updated (1904) so as to increment the update counter in the column (1905). Finally, theexecution module manager 106 releases the execution module condition table 1700 from exclusive locking (“N”) - 13. Operation
- In the above-mentioned structure, the
request queues transaction monitor 120. In addition to the operation of therequest queues preprocessor 103 sends an input message to anappropriate request queues message dictionary 114. The queuingcondition detection module 112 monitors conditions of therequest queues scheduler 104. TheScheduler 104 controls the requests on the basis of the information indicative of service priorities to plural service providers (customers) stored in the SLA database 113 (contract information related to service levels). Therefore, one transaction monitor 120 (or message broker) can be commonly used for plural customers while allocating each request to the optimum resource according to the predetermined priority or resource conditions, which makes it possible to guarantee proper throughput on any service. - The transaction processing system can be used in a data center that performs contract outsourcing of plural service providers' systems and centralized control of computer resources. This makes possible real time processing of more on-line transactions with less computer resources with maintaining the throughput guaranteed under contract with the customers. Thus the reliability and performance of the data center that integrally processes business transactions for plural customers can be improved.
- Further, the
dynamic loader 105 that implements necessary processes for each of services provided by plural service providers collectively loads updated modules before transaction processing, the updated modules being judged by theexecution module manager 106 that detects whether execution modules constituting each process are updated or not. Such a system makes it possible to change any service at any time when the transaction monitor 120 in operation without the need to provide means for disabling the routing of the execution modules or an auxiliary process group. Such a system can construct atransaction monitor 120 or message broker capable enhancing its flexibility and availability and making it easy to add and change business logic of customers with maintaining effective use of computer resources, which in turn makes the system operation easy. - FIGS. 16 and 17 shows the second embodiment.
- The first embodiment assumed a particular case where there was in the service flow execution routine107 a number of idling processes enough for the scheduler to schedule all the requests.
- In contrast, this embodiment assumes a normal case where the number of processes may not be secured due to limited computer resources and some processes needs to be traded off between services.
- This embodiment is provided with a
process manager 2001 instead of thescheduler 104. The other elements are the same as those in the first embodiment. - The
process manager 2001 is operative to control thedynamic loader 105 by estimating the number of processes to be required for the processing concerned from service conditions of therequest queues - After completion of a currently processed transaction, each process enters request acceptable state so that the next request can be extracted from a
corresponding request queue - A processing flow of the
process manager 2001 will be described based on FIG. 17. - Upon initiating the system, the
process manager 2001 obtains the SLA conditions (in FIG. 3) related to each service from theSLA database 113. Theprocess manager 2001 periodically monitors the queue and process conditions when the system is in operation (2103) to perform the following operations. - First of all, the
process manager 2001 obtains the queuing information related to each service from the queuing condition detection module 112 (2102). The queuing information includes the number of waiting requests and the oldest time stamp. As discussed with respect to FIG. 9, the queuing information can be obtained by referring to the queuinginformation field 1118 of the request header extracted by the queuingcondition detection module 112. - Next, for each service (2104), the
process manager 2001 obtains, from the service flow execution routine, the transaction starting time and finishing time and the number of processes corresponding to the service to calculate throughput to the transaction. In general, since plural processes correspond to one service (108, 109 in FIG. 16), the total throughput to the service concerned is determined by the sum of reciprocal numbers of time periods required for the transactions processed by the respective processes. - On the other hand, the
process manager 2001 determines, from the queuing information obtained, a difference between the previous queuing length and the current queuing length (the number of waiting requests in the queue) to calculate the frequency of arrival of requests. The frequency of arrival of requests can be calculated by dividing the difference in the queuing length by the time interval. - Alternatively, the
process manager 2001 may obtain a difference between the start time and stop time of each transaction to determine throughput to the transaction by multiplying the reciprocal number of the difference by the number of processes to be allocated for the service. - The total throughput thus obtained is compared with the frequency of arrival of requests, which makes it possible to estimate the level of satisfactory throughput to the service concerned.
- In other words, if the total throughput is larger in number than the frequency of arrival of requests, the queuing length is considered to be reduced with time. If it is smaller, the queuing length is considered to increase with time. Here, the level of satisfactory throughput is determined by dividing the total throughput by the frequency of arrival of requests (2109).
- After completion of determining the level of satisfactory throughput to each service, the
process manager 2001 changes the number of processes for the service to control the processes so that the optimum throughput will be distributed to each service. Here, theprocess manager 2001 newly calculates the number of processes needed to set the level of satisfactory throughput to one or more in the order of priority decided according to the SLA contract (2108). If the number of processes newly calculated is larger than the number of process currently existed, theprocess manager 2001 activates a number of processes corresponding to the difference between the newly calculated number and the existing number, and loads necessary execution modules through thedynamic loader 105 with keeping the loaded execution modules waiting (2112). - If the transaction monitor is limited in total number of processes and a necessary number of processes cannot be all activated, a number of processes are activated as many as possible (2113). On the other hand, if there is room in the level of satisfactory throughput, affordable processes are stopped to release their system resources (2114).
- Such a scheduling technique allows processes to be distributed to services having higher priorities in terms of SLA contract, which increase the probability of success in satisfying each service contract. At the same time, if there is room in the level of satisfactory throughput, affordable resources can also be allocated to such services that their priorities are low.
- In other words, even if a sufficient number of processes cannot be secured due to limited computer resources, an appropriate throughput can be secured according to each SLA contract, thus controlling the computer resources and hence improving the system's reliability.
- It should be noted here that when the frequency of arrival of requests largely varies, the operations shown in FIG. 17 may not be enough to prevent frequent start and stop of processes. To prevent excess variations in the number of processes, control can be carried out by taking into account histories of processes such as to prohibit the processes once activated from being stopped during a fixed time period.
- Further, in the case that many of high-priority requests are input, the operations in FIG. 17 may keep low-priority requests waiting a long time. In this case, the minimum number of processes for each service has only to be determined beforehand so that the number of processes can be increased or decreased in such a range that the number of processes is never below the predetermined number.
- Another feature of the second embodiment is transaction processing capable of providing one or more services and connecting one or more clients to each service. This feature is implemented by queuing means (110, 111) for storing processing requests from the clients for services while assigning priorities to the requests for each service, waiting condition obtaining means (queuing condition detection module 112) for obtaining waiting conditions of processing requests stored in the queuing means, and process allocating means (process manager 2001) for allocating processing processes of transactions to each service. In this configuration, the process allocating means decides the allocation of processes to each service by referring to the process request waiting conditions obtained and throughput to each transaction.
- To be more specific, a program for allocating processes is carried out by comparing the frequency of arrival of processing requests in a unit time, calculated from the processing request waiting conditions, with the throughput to the transaction. If the frequency of arrival of processing requests is larger than the throughput to the transaction, the number of processes to be allocated is increased. On the other hand, if the frequency of arrival of processing requests is smaller than the throughput to the transaction, the number of processes to be allocated is reduced.
Claims (12)
1. A transaction processing system capable of providing one or more services and connecting one or more clients to each service the system provides, comprising:
means for storing priority conditions defined according to the services provided; and
means of execution prioritization for deciding execution priorities to processing requests input from the clients to said transaction processing system by referring to the priority conditions held or stored in said priority condition storing means,
such that processing is carried out according to the decided priorities.
2. The system according to claim 1 , wherein said means of execution prioritization gives higher priorities to processing requests for services the priority conditions of which are defined high in priority.
3. A transaction processing system capable of providing one or more services and connecting one or more clients to each service the system provides, comprising:
means for storing priority conditions defined according to the services provided;
queuing means for storing processing requests sent from the clients for the services provided while putting the respective services into a particular order;
means for obtaining waiting conditions of the stored process requests from said queuing means; and
means of execution prioritization for deciding execution priorities to the processing requests input from the clients to said transaction processing system by referring to the priority conditions held or stored in said priority condition storing means and waiting conditions obtained,
such that processing is carried out according to the decided priorities.
4. The system according to claim 3 , wherein said means for obtaining waiting conditions obtains:
the number of processing requests that have been kept waiting in said queuing means; and
the time of arrival of each processing request that has been kept waiting in said queuing means.
5. The system according to claim 4 , wherein said means of execution prioritization decides the execution priority by comparing allowable waiting time defined for each provided service with the time of arrival of the processing request concerned obtained by said means for obtaining waiting conditions.
6. A transaction processing system capable of providing one or more services and connecting one or more clients to each service the system provides, comprising:
means for storing an identifier or identifiers of one or more execution modules constituting each service;
storage means for storing the execution module or modules; and
means for managing an update of each execution module on the basis of the identifier,
wherein when the execution module is updated by said update managing means, the updated execution module is placed to the storage means prior to starting the transaction corresponding to the service.
7. The system according to claim 6 , wherein said update managing means exclusively performs an update of one or more execution modules for each service and detection of the update of the execution modules.
8. A transaction processing system capable of providing one or more services and connecting one or more clients to each service the system provides, comprising:
queuing means for storing processing requests sent from the clients for the services provided while putting the respective services into a particular order;
means for obtaining waiting conditions of the process requests stored in said queuing means;
means for detecting transaction throughput to each service; and
means for allocating transaction processing processes to the service,
wherein said process allocating means decides the allocation of processes to the service by referring to the process request waiting conditions obtained and the transaction throughput detected.
9. The system according to claim 8 , wherein
said process allocating means increases the number of processes to be allocated as processing requests stored in said queuing means increases, and reduces the number of processes to be allocated as processing requests stored in said queuing means decreases.
10. The system according to claim 8 , wherein said process allocating means allocates processes according to the priority to be given to the service.
11. A program having a computer execute transaction processing capable of providing one or more services and connecting one or more clients to each of the services provided, comprising:
means for storing priority conditions defined according to the services in a priority condition database;
queuing means for storing, in a queue or queues, processing requests sent from the clients for the services provided while putting the respective services into a particular order;
means for obtaining waiting conditions of the stored process requests stored in the queue or queues;
means of execution prioritization for deciding execution priorities to the processing requests input from the clients to said transaction processing by referring to the priority conditions and the waiting conditions; and
means for letting the computer execute transaction processing according to the decided priorities.
12. A program having a computer execute transaction processing capable of providing one or more services and connecting one or more clients to each of the services provided, each service constituted of one or more execution modules, comprising:
means for judging update conditions of an execution module or modules on the basis of an identifier or identifiers of one or more execution modules constituting the service; and
means for placing updated execution module or modules if nay to storage means prior to starting the transaction or transactions corresponding to the service.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US11/208,522 US7756940B2 (en) | 2001-02-05 | 2005-08-23 | Transaction processing system having service level control capabilities |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2001-028231 | 2001-02-05 | ||
JP2001028231A JP4294879B2 (en) | 2001-02-05 | 2001-02-05 | Transaction processing system having service level control mechanism and program therefor |
Related Child Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US11/208,522 Continuation US7756940B2 (en) | 2001-02-05 | 2005-08-23 | Transaction processing system having service level control capabilities |
Publications (1)
Publication Number | Publication Date |
---|---|
US20020107743A1 true US20020107743A1 (en) | 2002-08-08 |
Family
ID=18892769
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US09/942,215 Abandoned US20020107743A1 (en) | 2001-02-05 | 2001-08-30 | Transaction processing system having service level control capabilities |
US11/208,522 Expired - Fee Related US7756940B2 (en) | 2001-02-05 | 2005-08-23 | Transaction processing system having service level control capabilities |
Family Applications After (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US11/208,522 Expired - Fee Related US7756940B2 (en) | 2001-02-05 | 2005-08-23 | Transaction processing system having service level control capabilities |
Country Status (2)
Country | Link |
---|---|
US (2) | US20020107743A1 (en) |
JP (1) | JP4294879B2 (en) |
Cited By (34)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20040117794A1 (en) * | 2002-12-17 | 2004-06-17 | Ashish Kundu | Method, system and framework for task scheduling |
US20040167980A1 (en) * | 2003-02-20 | 2004-08-26 | International Business Machines Corporation | Grid service scheduling of related services using heuristics |
WO2004095276A2 (en) * | 2003-04-17 | 2004-11-04 | International Business Machines Corporation | Corrective actions for servers with shared resources |
US20050165925A1 (en) * | 2004-01-22 | 2005-07-28 | International Business Machines Corporation | System and method for supporting transaction and parallel services across multiple domains based on service level agreenments |
US20050169173A1 (en) * | 2004-01-15 | 2005-08-04 | Novell, Inc. | Methods and systems for managing network traffic by multiple constraints |
US20050188075A1 (en) * | 2004-01-22 | 2005-08-25 | International Business Machines Corporation | System and method for supporting transaction and parallel services in a clustered system based on a service level agreement |
US20050198273A1 (en) * | 2004-03-04 | 2005-09-08 | International Business Machines Corporation | Event ownership assigner with failover for multiple event server system |
US20060173799A1 (en) * | 2005-01-31 | 2006-08-03 | Lodovico Minnocci | Technique for prioritizing tasks in a postal service provider data center |
US20060173800A1 (en) * | 2005-01-31 | 2006-08-03 | Mattern James M | Infrastructure with meter communication capabilities |
US20070027974A1 (en) * | 2005-08-01 | 2007-02-01 | Microsoft Corporation | Online service monitoring |
US20080056463A1 (en) * | 2006-08-29 | 2008-03-06 | Atte Lahtiranta | Voice mail extension |
US20080056155A1 (en) * | 2006-08-29 | 2008-03-06 | Atte Lahtiranta | Active idle extension |
US20080059627A1 (en) * | 2006-08-29 | 2008-03-06 | Hamalainen Jari P | Unified contact database |
US20080056454A1 (en) * | 2006-08-29 | 2008-03-06 | Atte Lahtiranta | Replying through different channels |
US20080155148A1 (en) * | 2006-10-26 | 2008-06-26 | Ozgur Oyman | Cooperative communication of data |
US20080243715A1 (en) * | 2007-04-02 | 2008-10-02 | Bank Of America Corporation | Financial Account Information Management and Auditing |
US20090192842A1 (en) * | 2008-01-29 | 2009-07-30 | International Business Machines Corporation | Computer Programs, Methods, Apparatus and Systems Providing Improved Evaluation of Business Processes |
US20090254411A1 (en) * | 2008-04-04 | 2009-10-08 | Kamal Bhattacharya | System and method for automated decision support for service transition management |
US7680897B1 (en) * | 2003-04-08 | 2010-03-16 | Novell, Inc. | Methods and systems for managing network traffic |
US20120072491A1 (en) * | 2004-05-17 | 2012-03-22 | Webalo, Inc. | User proxy server |
US8190561B1 (en) * | 2006-12-06 | 2012-05-29 | At&T Mobility Ii Llc | LDAP replication priority queuing mechanism |
US20130297562A1 (en) * | 2005-06-27 | 2013-11-07 | Ab Initio Technology Llc | Managing metadata for graph-based computations |
US20140006475A1 (en) * | 2012-06-29 | 2014-01-02 | Mckesson Financial Holdings | Method, apparatus, and computer program product for processing data requests |
US20150052057A2 (en) * | 2011-11-29 | 2015-02-19 | Giesecke & Devrient Gmbh | System and Method for Processing Bank Notes |
US20150310401A1 (en) * | 2014-04-28 | 2015-10-29 | Mastercard International Incorporated | Platform and Method for Analyzing the Performance of Message Oriented Middleware |
US9507682B2 (en) | 2012-11-16 | 2016-11-29 | Ab Initio Technology Llc | Dynamic graph performance monitoring |
US9753751B2 (en) | 2010-06-15 | 2017-09-05 | Ab Initio Technology Llc | Dynamically loading graph-based computations |
US9886319B2 (en) | 2009-02-13 | 2018-02-06 | Ab Initio Technology Llc | Task managing application for performing tasks based on messages received from a data processing application initiated by the task managing application |
US10108521B2 (en) | 2012-11-16 | 2018-10-23 | Ab Initio Technology Llc | Dynamic component performance monitoring |
US10628240B2 (en) | 2016-12-15 | 2020-04-21 | Ab Initio Technology Llc | Heterogeneous event queue |
US10657134B2 (en) | 2015-08-05 | 2020-05-19 | Ab Initio Technology Llc | Selecting queries for execution on a stream of real-time data |
US10901702B2 (en) | 2013-12-05 | 2021-01-26 | Ab Initio Technology Llc | Managing interfaces for sub-graphs |
JP6996271B2 (en) | 2017-12-13 | 2022-01-17 | 富士通株式会社 | Information processing equipment, information processing methods, and information processing programs |
US11609697B2 (en) * | 2011-06-30 | 2023-03-21 | Amazon Technologies, Inc. | System and method for providing a committed throughput level in a data store |
Families Citing this family (27)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7490083B2 (en) | 2004-02-27 | 2009-02-10 | International Business Machines Corporation | Parallel apply processing in data replication with preservation of transaction integrity and source ordering of dependent updates |
US8688634B2 (en) * | 2004-02-27 | 2014-04-01 | International Business Machines Corporation | Asynchronous peer-to-peer data replication |
CN101069384B (en) * | 2004-12-09 | 2010-05-05 | 国际商业机器公司 | Method and system for managing message-based work load in network environment |
JP4256897B2 (en) * | 2006-06-16 | 2009-04-22 | インターナショナル・ビジネス・マシーンズ・コーポレーション | Apparatus, method and program for providing matching service |
WO2008038386A1 (en) * | 2006-09-28 | 2008-04-03 | Fujitsu Limited | Service providing device, service providing system, and service providing method |
EP2128772A4 (en) | 2006-12-22 | 2014-11-12 | Ibm | Message hub, program, and method |
CN107423046B (en) * | 2007-07-26 | 2021-08-06 | 起元技术有限责任公司 | Method, system, and computer-readable medium for processing graph-based computations |
US8015327B1 (en) * | 2007-09-17 | 2011-09-06 | Emc Corporation | Techniques for monitoring and managing wait queues |
JP4941355B2 (en) * | 2008-02-27 | 2012-05-30 | 日本電気株式会社 | Residence data measurement system, method, and program |
JP5086934B2 (en) * | 2008-08-07 | 2012-11-28 | 株式会社三菱東京Ufj銀行 | Data processing apparatus and program |
JP5509564B2 (en) * | 2008-09-30 | 2014-06-04 | 富士通株式会社 | Message transmission method and program |
US8554967B2 (en) * | 2009-06-16 | 2013-10-08 | Freescale Semiconductor, Inc. | Flow control mechanisms for avoidance of retries and/or deadlocks in an interconnect |
US8667329B2 (en) | 2009-09-25 | 2014-03-04 | Ab Initio Technology Llc | Processing transactions in graph-based applications |
US8973000B2 (en) * | 2010-05-11 | 2015-03-03 | Hewlett-Packard Development Company, L.P. | Determining multiprogramming levels |
US8341134B2 (en) * | 2010-12-10 | 2012-12-25 | International Business Machines Corporation | Asynchronous deletion of a range of messages processed by a parallel database replication apply process |
JP5569424B2 (en) * | 2011-02-14 | 2014-08-13 | 富士通株式会社 | Update apparatus, update method, and update program |
US8789058B2 (en) * | 2011-03-25 | 2014-07-22 | Oracle International Corporation | System and method for supporting batch job management in a distributed transaction system |
JP5295395B2 (en) * | 2012-01-04 | 2013-09-18 | 株式会社三菱東京Ufj銀行 | Data processing device |
JP5924073B2 (en) * | 2012-03-30 | 2016-05-25 | 富士通株式会社 | Control program, control method, and control apparatus |
JP6010975B2 (en) * | 2012-03-30 | 2016-10-19 | 日本電気株式会社 | Job management apparatus, job management method, and program |
US20170358017A1 (en) * | 2012-06-26 | 2017-12-14 | Google Inc. | Price breaks in a cloud computing system for using an automatic scheduler |
JP5604554B2 (en) * | 2013-04-30 | 2014-10-08 | 株式会社三菱東京Ufj銀行 | Data processing device |
US9727625B2 (en) | 2014-01-16 | 2017-08-08 | International Business Machines Corporation | Parallel transaction messages for database replication |
JP6399587B2 (en) * | 2014-10-22 | 2018-10-03 | シャープ株式会社 | Information processing apparatus, information processing system, information processing method, and information processing program |
US10104187B2 (en) * | 2016-06-15 | 2018-10-16 | Futurewei Technologies, Inc. | System, computer program, and method for dividing services into subsets based on interdependencies |
CN106204263B (en) * | 2016-06-30 | 2019-09-24 | 中国农业银行股份有限公司 | Transaction progress control method and device |
US11424994B2 (en) * | 2019-05-16 | 2022-08-23 | Fortuna Identity Inc | Traffic-controlled processing of application requests |
Citations (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5594905A (en) * | 1995-04-12 | 1997-01-14 | Microsoft Corporation | Exception handler and method for handling interrupts |
US6324625B1 (en) * | 1999-03-16 | 2001-11-27 | Fujitsu Network Communications, Inc. | Rotating rationed buffer refresh |
US6378051B1 (en) * | 1999-06-14 | 2002-04-23 | Maxtor Corporation | Interrupt signal prioritized shared buffer memory access system and method |
US6681230B1 (en) * | 1999-03-25 | 2004-01-20 | Lucent Technologies Inc. | Real-time event processing system with service authoring environment |
US6701324B1 (en) * | 1999-06-30 | 2004-03-02 | International Business Machines Corporation | Data collector for use in a scalable, distributed, asynchronous data collection mechanism |
US6724885B1 (en) * | 2000-03-31 | 2004-04-20 | Lucent Technologies Inc. | Automatic call distribution center with queue position restoration for call-back customers |
Family Cites Families (25)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JPS6219957A (en) | 1985-07-19 | 1987-01-28 | Hitachi Ltd | Preventing system for depression state of transaction |
JPH04358228A (en) | 1991-06-04 | 1992-12-11 | Nec Corp | Process number control system |
JPH0512226A (en) | 1991-06-28 | 1993-01-22 | Toshiba Corp | Composite electronic computer system |
JPH0628323A (en) | 1992-07-06 | 1994-02-04 | Nippon Telegr & Teleph Corp <Ntt> | Process execution control method |
JPH0652121A (en) | 1992-07-31 | 1994-02-25 | Toshiba Corp | Transaction processing system |
JPH06243077A (en) | 1993-02-19 | 1994-09-02 | Hitachi Ltd | Distributed transaction processing system |
JP2919240B2 (en) | 1993-09-02 | 1999-07-12 | 日本電気株式会社 | I / O priority control method |
ES2149794T3 (en) * | 1993-09-24 | 2000-11-16 | Siemens Ag | PROCEDURE TO OFFSET THE LOAD IN A MULTIPROCESSOR SYSTEM. |
US5675739A (en) * | 1995-02-03 | 1997-10-07 | International Business Machines Corporation | Apparatus and method for managing a distributed data processing system workload according to a plurality of distinct processing goal types |
JPH0962624A (en) | 1995-08-28 | 1997-03-07 | Hitachi Ltd | Processing method and processing system for on-line transaction |
JP2921501B2 (en) | 1996-07-26 | 1999-07-19 | 日本電気株式会社 | Task execution priority change method under high load in online processing system |
US6226377B1 (en) * | 1998-03-06 | 2001-05-01 | Avaya Technology Corp. | Prioritized transaction server allocation |
US6055564A (en) * | 1998-03-11 | 2000-04-25 | Hewlett Packard Company | Admission control where priority indicator is used to discriminate between messages |
US6157963A (en) * | 1998-03-24 | 2000-12-05 | Lsi Logic Corp. | System controller with plurality of memory queues for prioritized scheduling of I/O requests from priority assigned clients |
US6154769A (en) * | 1998-03-27 | 2000-11-28 | Hewlett-Packard Company | Scheduling server requests to decrease response time and increase server throughput |
US6205150B1 (en) * | 1998-05-28 | 2001-03-20 | 3Com Corporation | Method of scheduling higher and lower priority data packets |
GB2338372B (en) * | 1998-06-12 | 2003-08-27 | Ericsson Telefon Ab L M | Architecture for integrated services packet-switched networks |
JP3684308B2 (en) * | 1998-12-15 | 2005-08-17 | 富士通株式会社 | Scheduling control device and exchange |
US7046665B1 (en) * | 1999-10-26 | 2006-05-16 | Extreme Networks, Inc. | Provisional IP-aware virtual paths over networks |
US6442550B1 (en) * | 1999-12-14 | 2002-08-27 | International Business Machines Corporation | System and method in a collaborative data processing environment for customizing the quality of service on a per-client basis |
US6910024B2 (en) * | 2000-02-04 | 2005-06-21 | Hrl Laboratories, Llc | System for pricing-based quality of service (PQoS) control in networks |
US6882623B1 (en) * | 2000-02-08 | 2005-04-19 | Native Networks Technologies Ltd. | Multi-level scheduling method for multiplexing packets in a communications network |
US7075927B2 (en) * | 2000-05-05 | 2006-07-11 | Fujitsu Limited | Method and system for quality of service (QoS) support in a packet-switched network |
US6950885B2 (en) * | 2001-09-25 | 2005-09-27 | Intel Corporation | Mechanism for preventing unnecessary timeouts and retries for service requests in a cluster |
WO2005108928A1 (en) | 2004-05-07 | 2005-11-17 | Pioneer Corporation | Route search device, route search method, route search processing program, etc. |
-
2001
- 2001-02-05 JP JP2001028231A patent/JP4294879B2/en not_active Expired - Fee Related
- 2001-08-30 US US09/942,215 patent/US20020107743A1/en not_active Abandoned
-
2005
- 2005-08-23 US US11/208,522 patent/US7756940B2/en not_active Expired - Fee Related
Patent Citations (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5594905A (en) * | 1995-04-12 | 1997-01-14 | Microsoft Corporation | Exception handler and method for handling interrupts |
US6324625B1 (en) * | 1999-03-16 | 2001-11-27 | Fujitsu Network Communications, Inc. | Rotating rationed buffer refresh |
US6681230B1 (en) * | 1999-03-25 | 2004-01-20 | Lucent Technologies Inc. | Real-time event processing system with service authoring environment |
US6378051B1 (en) * | 1999-06-14 | 2002-04-23 | Maxtor Corporation | Interrupt signal prioritized shared buffer memory access system and method |
US6701324B1 (en) * | 1999-06-30 | 2004-03-02 | International Business Machines Corporation | Data collector for use in a scalable, distributed, asynchronous data collection mechanism |
US6724885B1 (en) * | 2000-03-31 | 2004-04-20 | Lucent Technologies Inc. | Automatic call distribution center with queue position restoration for call-back customers |
Cited By (54)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20040117794A1 (en) * | 2002-12-17 | 2004-06-17 | Ashish Kundu | Method, system and framework for task scheduling |
US7243351B2 (en) * | 2002-12-17 | 2007-07-10 | International Business Machines Corporation | System and method for task scheduling based upon the classification value and probability |
US7171470B2 (en) * | 2003-02-20 | 2007-01-30 | International Business Machines Corporation | Grid service scheduling of related services using heuristics |
US20040167980A1 (en) * | 2003-02-20 | 2004-08-26 | International Business Machines Corporation | Grid service scheduling of related services using heuristics |
US7680897B1 (en) * | 2003-04-08 | 2010-03-16 | Novell, Inc. | Methods and systems for managing network traffic |
CN100419697C (en) * | 2003-04-17 | 2008-09-17 | 国际商业机器公司 | Corrective actions for servers with shared resources |
WO2004095276A3 (en) * | 2003-04-17 | 2004-12-29 | Ibm | Corrective actions for servers with shared resources |
US7992033B2 (en) | 2003-04-17 | 2011-08-02 | International Business Machines Corporation | System management infrastructure for corrective actions to servers with shared resources |
US20090183024A1 (en) * | 2003-04-17 | 2009-07-16 | Childress Rhonda L | System Management Infrastructure for Corrective Actions to Servers with Shared Resources |
US7529981B2 (en) | 2003-04-17 | 2009-05-05 | International Business Machines Corporation | System management infrastructure for corrective actions to servers with shared resources |
WO2004095276A2 (en) * | 2003-04-17 | 2004-11-04 | International Business Machines Corporation | Corrective actions for servers with shared resources |
US20050169173A1 (en) * | 2004-01-15 | 2005-08-04 | Novell, Inc. | Methods and systems for managing network traffic by multiple constraints |
US7546367B2 (en) | 2004-01-15 | 2009-06-09 | Novell, Inc. | Methods and systems for managing network traffic by multiple constraints |
US20050188075A1 (en) * | 2004-01-22 | 2005-08-25 | International Business Machines Corporation | System and method for supporting transaction and parallel services in a clustered system based on a service level agreement |
US8346909B2 (en) | 2004-01-22 | 2013-01-01 | International Business Machines Corporation | Method for supporting transaction and parallel application workloads across multiple domains based on service level agreements |
US20050165925A1 (en) * | 2004-01-22 | 2005-07-28 | International Business Machines Corporation | System and method for supporting transaction and parallel services across multiple domains based on service level agreenments |
US8224937B2 (en) | 2004-03-04 | 2012-07-17 | International Business Machines Corporation | Event ownership assigner with failover for multiple event server system |
US20050198273A1 (en) * | 2004-03-04 | 2005-09-08 | International Business Machines Corporation | Event ownership assigner with failover for multiple event server system |
US20120072491A1 (en) * | 2004-05-17 | 2012-03-22 | Webalo, Inc. | User proxy server |
US20060173800A1 (en) * | 2005-01-31 | 2006-08-03 | Mattern James M | Infrastructure with meter communication capabilities |
US20060173799A1 (en) * | 2005-01-31 | 2006-08-03 | Lodovico Minnocci | Technique for prioritizing tasks in a postal service provider data center |
US7890432B2 (en) * | 2005-01-31 | 2011-02-15 | Neopost Technologies | Infrastructure with meter communication capabilities |
US9158797B2 (en) * | 2005-06-27 | 2015-10-13 | Ab Initio Technology Llc | Managing metadata for graph-based computations |
US20130297562A1 (en) * | 2005-06-27 | 2013-11-07 | Ab Initio Technology Llc | Managing metadata for graph-based computations |
US20070027974A1 (en) * | 2005-08-01 | 2007-02-01 | Microsoft Corporation | Online service monitoring |
US20080056463A1 (en) * | 2006-08-29 | 2008-03-06 | Atte Lahtiranta | Voice mail extension |
US20080056155A1 (en) * | 2006-08-29 | 2008-03-06 | Atte Lahtiranta | Active idle extension |
US20080059627A1 (en) * | 2006-08-29 | 2008-03-06 | Hamalainen Jari P | Unified contact database |
US8385517B2 (en) | 2006-08-29 | 2013-02-26 | Nokia Corporation | Replying through different channels |
US8363794B2 (en) | 2006-08-29 | 2013-01-29 | Nokia Corporation | Voice mail extension |
US20080056454A1 (en) * | 2006-08-29 | 2008-03-06 | Atte Lahtiranta | Replying through different channels |
US20080155148A1 (en) * | 2006-10-26 | 2008-06-26 | Ozgur Oyman | Cooperative communication of data |
US8190561B1 (en) * | 2006-12-06 | 2012-05-29 | At&T Mobility Ii Llc | LDAP replication priority queuing mechanism |
US8099345B2 (en) * | 2007-04-02 | 2012-01-17 | Bank Of America Corporation | Financial account information management and auditing |
US20080243715A1 (en) * | 2007-04-02 | 2008-10-02 | Bank Of America Corporation | Financial Account Information Management and Auditing |
US20090192842A1 (en) * | 2008-01-29 | 2009-07-30 | International Business Machines Corporation | Computer Programs, Methods, Apparatus and Systems Providing Improved Evaluation of Business Processes |
US8103535B2 (en) * | 2008-01-29 | 2012-01-24 | International Business Machines Corporation | Evaluation of fitness for a contractual agreement related to provisioning information technology services |
US20090254411A1 (en) * | 2008-04-04 | 2009-10-08 | Kamal Bhattacharya | System and method for automated decision support for service transition management |
US10528395B2 (en) | 2009-02-13 | 2020-01-07 | Ab Initio Technology Llc | Task managing application for performing tasks based on messages received from a data processing application initiated by the task managing application |
US9886319B2 (en) | 2009-02-13 | 2018-02-06 | Ab Initio Technology Llc | Task managing application for performing tasks based on messages received from a data processing application initiated by the task managing application |
US9753751B2 (en) | 2010-06-15 | 2017-09-05 | Ab Initio Technology Llc | Dynamically loading graph-based computations |
US11609697B2 (en) * | 2011-06-30 | 2023-03-21 | Amazon Technologies, Inc. | System and method for providing a committed throughput level in a data store |
US20150052057A2 (en) * | 2011-11-29 | 2015-02-19 | Giesecke & Devrient Gmbh | System and Method for Processing Bank Notes |
US9990794B2 (en) * | 2011-11-29 | 2018-06-05 | Giesecke+Devrient Currency Technology Gmbh | System and method for processing bank notes |
US20140006475A1 (en) * | 2012-06-29 | 2014-01-02 | Mckesson Financial Holdings | Method, apparatus, and computer program product for processing data requests |
US9319449B2 (en) * | 2012-06-29 | 2016-04-19 | Mckesson Financial Holdings | Method, apparatus, and computer program product for processing data requests |
US10108521B2 (en) | 2012-11-16 | 2018-10-23 | Ab Initio Technology Llc | Dynamic component performance monitoring |
US9507682B2 (en) | 2012-11-16 | 2016-11-29 | Ab Initio Technology Llc | Dynamic graph performance monitoring |
US10901702B2 (en) | 2013-12-05 | 2021-01-26 | Ab Initio Technology Llc | Managing interfaces for sub-graphs |
US9990630B2 (en) * | 2014-04-28 | 2018-06-05 | Mastercard International Incorporated | Platform and method for analyzing the performance of message oriented middleware |
US20150310401A1 (en) * | 2014-04-28 | 2015-10-29 | Mastercard International Incorporated | Platform and Method for Analyzing the Performance of Message Oriented Middleware |
US10657134B2 (en) | 2015-08-05 | 2020-05-19 | Ab Initio Technology Llc | Selecting queries for execution on a stream of real-time data |
US10628240B2 (en) | 2016-12-15 | 2020-04-21 | Ab Initio Technology Llc | Heterogeneous event queue |
JP6996271B2 (en) | 2017-12-13 | 2022-01-17 | 富士通株式会社 | Information processing equipment, information processing methods, and information processing programs |
Also Published As
Publication number | Publication date |
---|---|
JP4294879B2 (en) | 2009-07-15 |
US7756940B2 (en) | 2010-07-13 |
JP2002229943A (en) | 2002-08-16 |
US20060031286A1 (en) | 2006-02-09 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US7756940B2 (en) | Transaction processing system having service level control capabilities | |
CN111522639B (en) | Multidimensional resource scheduling method under Kubernetes cluster architecture system | |
US5504894A (en) | Workload manager for achieving transaction class response time goals in a multiprocessing system | |
KR100322724B1 (en) | Apparatus and method for scheduling and dispatching queued client requests within a server in a client/server computer system | |
EP3770774B1 (en) | Control method for household appliance, and household appliance | |
EP1974269B1 (en) | Connection manager handling sessions based on shared session information | |
JP3944154B2 (en) | Method and system for dynamically adjusting a thread pool in a multi-threaded server | |
US5797005A (en) | Shared queue structure for data integrity | |
EP0568002B1 (en) | Distribution of communications connections over multiple service access points in a communications network | |
RU2465634C2 (en) | Real-time instruction processing system | |
US6393455B1 (en) | Workload management method to enhance shared resource access in a multisystem environment | |
US7657450B2 (en) | Reliable, secure and scalable infrastructure for event registration and propagation in a distributed enterprise | |
US8621480B2 (en) | Load balancer with starvation avoidance | |
US5924097A (en) | Balanced input/output task management for use in multiprocessor transaction processing system | |
US7734676B2 (en) | Method for controlling the number of servers in a hierarchical resource environment | |
EP1472846B1 (en) | Method and apparatus for web farm traffic control | |
US5325526A (en) | Task scheduling in a multicomputer system | |
US9390130B2 (en) | Workload management in a parallel database system | |
US6338072B1 (en) | Device and process for dynamically controlling the allocation of resources in a data processing system | |
CN111901249B (en) | Service flow limiting method, device, equipment and storage medium | |
EP1564638B1 (en) | A method of reassigning objects to processing units | |
US6216127B1 (en) | Method and apparatus for processing electronic mail in parallel | |
US20070300239A1 (en) | Dynamic application instance placement in data center environments | |
EP0723236A2 (en) | System for communicating messages among agent processes | |
US20110173252A1 (en) | System and method for context-based serialization of messages in a parallel execution environment |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: HITACHI, LTD., JAPAN Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:SAGAWA, NOBUTOSHI;REEL/FRAME:012130/0893 Effective date: 20010717 |
|
STCB | Information on status: application discontinuation |
Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION |