Abstract:
PROBLEM TO BE SOLVED: To reduce many inter-process flows related to the processing of respective transactions and to reduce the overhead of a client process following the preparation of respective transactions. SOLUTION: A client processor to be used for a client/server calculation system for processing each transaction issues a start command in order to inform the start of a transaction and transmits a substantial transaction command to a remote server. The transaction command includes a transaction context having a specific value for indicating that a transaction has been started but a transaction object 332 expressing the transaction is not prepared yet. When the remote server prepares the object 332, the client processor receives a corrected transaction context from the remote server.
Abstract:
PROBLEM TO BE SOLVED: To simplify the job of an application writer by locally generating a transaction when a client can be restored, and remotely generating the transaction when the client can not be restored. SOLUTION: A client computer 10 is provided with an application program 40. When the client computer 10 desires a request for the service of a server computer 20, the first application program 40 communicates the request for the service to a first logical means 50. A transaction start command is written regardless of whether or not the client 10 can be restored, and when the client 10 can be restored, a transaction is locally generated on the client 10, and when the client 10 can not be restored, the transaction is remotely generated for the client 10 in response to the transaction start command.
Abstract:
PROBLEM TO BE SOLVED: To reduce flows among many processes relating to the processings of respective transactions and to provide high flexibility for the processing method of the respective transactions. SOLUTION: This server processing method to be used in a client/server computing system for processing the transaction is provided with a stage for receiving (81) a command for reporting the start of the transaction from a client process, the stage for deciding (82) whether or not a local transaction preparation means is present and the stage for transferring (84) the command to the other server in the case that the local transaction preparation means is not present and locally preparing (83) transaction state data in the case that the local transaction preparation means is present.
Abstract:
A data processing apparatus (10, FIG. 1) has a direct access non-volatile storage device (103) on which log records are stored in one or more log files. The processor (101) allocates storage for the log based on possible future requirements. The processor sets the maximum amount of new data that can be written to the log before a key-point operation is performed. When the maximum is reached a key-point is performed. As a result the maximum possible size of the active data written as part of the next key-point can be calculated and storage is allocated accordingly. Should storage become restricted such that the required storage cannot be allocated the data processing apparatus runs in a restricted mode during which the records that are written to the log are concerned with reducing the size of the active data and therefore the next key-point. In transaction processing this is achieved by: not starting new transactions; not allowing transactions to involve new participants; and only allowing transactions to complete.
Abstract:
A client processing apparatus for use in a client/server computing system which carries out transactions, issues a begin command to signify the beginning of a transaction; sends a substantive transactional command to a remote server, said command including a transaction context having a specific value which indicates that a transaction has been started but transaction objects which represent the transaction have not yet been created; and receives a modified transaction context from said remote server once said remote server has created said transaction objects.
Abstract:
The processor includes a descriptor associated with each activity instance. The descriptor comprises parameters for determining life time behavior of activity instance. The descriptor is programmed suitably to change life time behavior according to use of instance. Independent claims are also included for the following: (a) Activities processing method; (b) Computer program
Abstract:
A server in a client/server computing system where a distributed transaction is being carried out, has: a server resource having local data associated therewith; a software element for receiving a registration request from the server resource requesting that the server resource be registered in a transaction, after the server resource has received the transaction context in the explicit transaction propagation mode; and a software element for creating a distributed transaction object representing the transaction in response to receipt of the registration request, the distributed transaction object persisting until the transaction is completed.
Abstract:
A mapping processor (106) reads imaged values (107) from a table, corresponding to heterogeneous user input components (102,103) for the commitment or reset request. A result processor (108) is programmed to process the input imaged values using different Boolean expressions and to output the result (109) to the users. Independent claims are also included for the following: (a) Batch processing method; (b) Batch processing program stored in memory medium
Abstract:
Transaction processing in a distributed (client/server) computing system. A transaction is created by setting up transaction state objects in a server process (22, figs. 2 and 3). Whereas normally, Control, Terminator and Coordinator objects (221-223, fig. 2) would be instantiated, according to the invention only the Control and Terminator objects (221, 222, fig. 3) are instantiated, 42. The Coordinator object coordinates the transaction with respect to a plurality of resources according to the two phase commit protocol, and is created at a later stage in the transaction, 44, only in response to a predetermined trigger event, such as the server receiving a request to update a local resource, 43, or another server process being called by the transaction, 45. Since the Coordinator object is thus only created if, and when, needed by the transaction, processor cycles are saved; this also prevents the transaction from having to be logged to storage (225, fig. 2) when such logging is unnecessary for the presently executing transaction.
Abstract:
Transaction processing in a distributed object-oriented environment. Server 21 stores transaction state data including coordinator object 211, and server 22 has resource object 221 which receives a transaction context of the transaction represented by coordinator object 211, via the explicit transaction propagation mode. Server resource 221 makes a transaction registration request to customised coordinator proxy (CCP) object 222, and CCP object 222 creates a distributed transaction resource (DTR) object 223 representing the transaction. DTR object 223 registers with remote coordinator object 211, may create duplicate CCP object 222', forwards the 2-phase commit protocols to server resource 221 and then destroys duplicate CCP object 222' and itself. Since the DTR and duplicate CCP objects persist in server 22 during the lifetime of the transaction, even though original CCP object 222 is destroyed as soon as the resource object 221's direct involvement with the transaction has finished, these transaction representations can be counted to determine the total number of transactions currently pending in which the server is involved.