(Cat? OR feline) AND NOT dog?
Cat? W/5 behavior
(Cat? OR feline) AND traits
Cat AND charact*

This guide provides a more detailed description of the syntax that is supported along with examples.

This search box also supports the look-up of an IP.com Digital Signature (also referred to as Fingerprint); enter the 72-, 48-, or 32-character code to retrieve details of the associated file or submission.

Concept Search - What can I type?

For a concept search, you can enter phrases, sentences, or full paragraphs in English. For example, copy and paste the abstract of a patent application or paragraphs from an article.

Concept search eliminates the need for complex Boolean syntax to inform retrieval. Our Semantic Gist engine uses advanced cognitive semantic analysis to extract the meaning of data. This reduces the chances of missing valuable information, that may result from traditional keyword searching.

Runtime Transaction Management in a Transaction Service

Publishing Venue

IBM

Related People

Hutchison, G: AUTHOR

Abstract

With traditional transaction servers, administration of transactions is greatly facilitated by the concept of a Transaction ID (e.g. CECI). This allows administrators and other users to observe transactional activity in the system grouped by transaction classes that have conceptual meaning to the users for the purposes of system monitoring, debugging and manual intervention in heuristic resync etc.

Country

United States

Language

English (United States)

This text was extracted from an ASCII text file.

This is the abbreviated version, containing approximately
36% of the total text.

Runtime Transaction Management in a Transaction Service

With traditional
transaction servers, administration of
transactions is greatly facilitated by the concept of a Transaction
ID (e.g. CECI). This allows
administrators and other users to
observe transactional activity in the system grouped by transaction
classes that have conceptual meaning to the users for the purposes of
system monitoring, debugging and manual intervention in heuristic
resync etc.

However in the
CORBA* defined Object Transaction Service
(OTS) as implemented in Component Broker (CB) and the Java**
Transaction Service (JTS) there is no analogous concept to a
transaction ID. Transactions are all
created as instances of the
same class 'Transaction' and are represented by a sequence of octets
(a byte string). Transactions propagate
between processes in a
similar manner, they can be compared for equality and such like but
there is no mechanism for grouping them into types or classes of
transaction that can be used to provide conceptual information for
the administrator.

This means that
systems like CB and JTS are much more
confusing to administer in cases where human understanding of
transactional activity is necessary (e.g. debugging or heuristic
hazard situations).

For example the
JTS has implemented an administration
interface which allows users to view and control the transactions in
a server.

Actions that
administrators will most commonly use this
interface for are observing transactional activity, resolving
deadlocks and manually forcing transaction completion in heuristic
situations.

As is apparent,
it is difficult for a human to be able to
deduce any useful information on what type of transaction he/she is
observing (or about to heuristically rollback for example).

This is bad as
transactions do not exit in isolation and
any heuristic action may well have to be reflected with similar
action in another server. If the
administrator was in a situation
requiring the transaction to be forced, it is impossible for him/her
to tell what other systems the transaction could have flowed to (or
to make any sensible guess) based on the transaction id. His/her
best option currently is to search all possible servers looking for
an occurence of the same transaction id sequence.

The approach
described here enables a significant
improvement in usability of the transaction administration in a
system such as CB.

In a running
CORBA transaction system work (and
transactions) flow in and out of system processes in object packages
of type CORBA::request. When a
transaction is propogated into a
running server process it will be attached to a particular request.
This request will always be targeted at an object that is marked as
being 'transactional' by descending from (or implementing) the
CosTransactions::TransactionalObject interface.
However the target
object will also be of a particular type or 'Interface' in Corba
Terminology. ...