Data processing: database and file management or data structures – Database design – Data structure types
Reexamination Certificate
2001-05-22
2004-07-20
Mizrahi, Diane D. (Department: 2175)
Data processing: database and file management or data structures
Database design
Data structure types
C707S793000
Reexamination Certificate
active
06766323
ABSTRACT:
FIELD OF THE INVENTION
The present invention relates to application support in a data processing system.
BACKGROUND OF THE INVENTION
In distributed computing environments today, an increasingly large number of distributed applications, (that is to say user programs), are developed using a number of pre-existing applications and may run over an extended period of time. There is a need for systems to support these long-running applications for several reasons. One reason is that the long-running applications may be cumbersome, having complex structures and complex inter-relationships between the constituent applications. Additionally, because the applications often take a long time to complete they may remain inactive for long periods, whilst awaiting user interactions. These long-running applications may also require support for fault tolerance if machines fail or if services are moved or withdrawn.
An example of a distributed environment in which the long-running applications may run is shown in
FIG. 1. A
client/server data processing apparatus (
100
) is connected to other client/server data processing apparatus (
120
) and (
130
) via a network (
110
), which could be, for example, the Internet. The client/servers (
100
), (
120
) and (
130
) interact with each other, in the preferred embodiment, to carry out work, such as the processing of transactions (for example, transactions to update bank accounts). Client/server (
100
) has a processor (
101
) for executing programs that control the operation of the client/server (
100
). Client/server (
100
) also has a RAM volatile memory element (
102
), a non-volatile memory (
103
), and a network connector (
104
) for use in interfacing with the network (
110
) for communication with the other client/servers (
120
,
130
).
Although each client/server in
FIG. 1
is capable of sending and receiving messages from the network, whether they behave as a client and/or servers will depend on the programs that are used to control their operation. These programs can often run several processes on each client/server and these processes can be client or server processes. As a result it is possible for a client/server data processing apparatus to run several processes some of which behave as clients on the network and others that behave as servers on the network
Referring to
FIG. 2
, a long-running application (
200
) may also be developed by utilising a number of individual transactions (
210
-
260
) running in series or in parallel. Transactions may be nested, whereby one transaction (a child) may be nested within another transaction (the parent). A top-level or root transaction is one that does not participate in nesting.
A transaction is a sequence of co-ordinated operations on system resources such that either all of the changes take effect or none of them does. The coordinated operations are typically changes made to data held in storage in the transaction processing system, system resources include databases, data tables, files, data records and so on. This characteristic of a transaction being accomplished as a whole, or not at all, is also known as atomicity (A). A transaction is also consistent (C) and this characteristic falls under the responsibility of the application. A transaction is also carried out in isolation (I) via locking mechanisms and is durable (D), in that the effects of a transaction must be evident and persistent. These characteristics are often known as the ‘ACID’ properties of an individual transaction.
Alternatively, a long-running application may comprise a number of individual activities at arbitrary points during its lifetime. Referring to
FIG. 3
, an application (
300
) may also comprise a combination of transactions (
315
,
320
) and activities (
305
,
310
). An activity is a single unit of distributed work that encompasses a particular piece of logic. An activity may have transactional or non-transactional behaviour during its lifetime and furthermore, a number of activities may be nested in a hierarchy, whereby a nested activity is a child of a parent activity.
Referring to
FIG. 4
, a series of connected activities (
430
,
435
,
440
,
445
,
450
) co-operating during an application's (
425
) lifetime is shown. A first activity (
430
) utilises two top-level transactions (
432
,
434
) during its execution. A second activity (
440
) comprises a transaction (
441
) and additionally comprises a nested activity (
442
). The nested activity (
442
) further comprises a transaction (
443
).
The structuring of applications as several short-duration transactions, rather than as a single top-level transaction has many advantages. One advantage is that the application acquires and uses resources for only the required duration, rather than for the entire duration of that application.
However, current problems with application structuring mechanisms include the fact that when an application comprising a number of individual transactions is executed, there may be a requirement for the application to possess some or all of the ACID properties not normally associated with the application. However, the process to enable the application to possess some or all of these ACID properties currently involves a manual overhead, whereby a programmer builds application-specific mechanisms.
Additionally, if failures or concurrent access occurs during the lifetime of the application, then the behaviour of the entire logical long-running application may not possess the ACID properties. Some form of application-specific compensation is therefore required to attempt to return the state of the system to application-specific consistency. For example, compensation transactions, which perform forward or backward recovery in order to obtain transactional semantics for the entire long-running application, may be required.
One solution to these problems is the low-level architecture, described by the OMG “Activity Service”. Further information on the Activity Service can be found in the document “Additional Structuring Mechanisms for the OTS Specification”, by IBM et al, 2000 available at http://www.omg.org. (IBM is a registered trademark of International Business Machines Corporation.)
The Activity Service is an object framework, upon which high-level services can be constructed to represent a variety of extended transaction models that may then support more complex transactional semantics than the simple ACID properties. Referring to
FIG. 5
, the Activity Service (
500
) provides support for high-level services (
510
,
520
) which can be built on top of it, whereby a high-level service (
510
) is utilised by an application. An OTS (
530
) may or may not be built on top of the Activity Service. An activity can therefore represent a particular high-level service or a transaction.
One main component of the Activity Service is a “context”. A context, in terms of activities, is activity information associated with a specific thread. An activity performing an operation does so within its context and since activities can be nested, contexts can also be nested. Another component in the Activity Service is a “property”, which represents application-specific information. A “Property Group” is a tuple-space of attribute-value pairs for specifying application-specific data.
The current activity service model provides useful functions for the high-level services, such as context demarcation and context propagation. The Activity Service provides general support for demarcation of work that can span multiple ACID transactions and for managing application-specified context data that is made globally available within that demarcation scope. It provides interfaces to specify demarcation boundaries for units of activity, and provides a distributed service context that is implicitly propagated, via an ORB, on remote requests.
Propagation will now be described in more detail with reference to FIG.
6
. Multiple threads may be associated with a single activity at any one same time. The multiple threads may be present in the same execution environment
Beaven John Anthony
Colby Logan
Mulholland Alexandra
Robinson Ian
Mizrahi Diane D.
Mofiz Apu M
Roth Steven W.
LandOfFree
System, method and computer program for application support... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with System, method and computer program for application support..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and System, method and computer program for application support... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3244761