Browse Prior Art Database

Hierarchical "Switch after Discard" Algorithm for Units of Work Within an Object Oriented Environment

IP.com Disclosure Number: IPCOM000112990D
Original Publication Date: 1994-Jun-01
Included in the Prior Art Database: 2005-Mar-27
Document File: 2 page(s) / 83K

Publishing Venue

IBM

Related People

Rich, W: AUTHOR [+2]

Abstract

In ProductManager*, units of work are kept in a list, in most recently used order. This ordering can lead to additional code in the applications to ensure that the unit of work environment is properly maintained. Thus, it was decided to change the list of units of work in to a tree of units of work to reduce the coding needed in the applications.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 52% of the total text.

Hierarchical "Switch after Discard" Algorithm for Units of Work Within
an Object Oriented Environment

      In ProductManager*, units of work are kept in a list, in most
recently used order.  This ordering can lead to additional code in
the applications to ensure that the unit of work environment is
properly maintained.  Thus, it was decided to change the list of
units of work in to a tree of units of work to reduce the coding
needed in the applications.

      There are two ways to alter the current unit of work
environment.  One way is to switch to another unit of work, which
will make that unit of work the current unit of work.  If a method
temporarily switches to another unit of work to perform an operation,
it must restore the caller's unit of work environment by switching
back to the current unit of work.

      The second way to alter the current unit of work environment is
to create a new unit of work.  Any method that creates a temporary
unit of work should discard it before returning to the caller.
However, this does not guarantee that the caller's unit of work will
be restored.  The unit of work that is made current after a unit of
work discard is the second most recently current unit of work.  This
may or may not be the caller's unit of work, depending on the logic
flow within the applications.

      There are two ways to correctly restore the caller's unit of
work environment after a unit of work discard.  One is to save the
caller's unit of work and switch to it after discarding any newly
created temporary unit of work.  This would involve adding a lot of
code to the applications.  The second choice would be to change the
semantics of unit of work discard, so that the unit of work that was
current when the new unit of work was created would become current
when the unit of work was discarded.  This last approach was taken in
order to reduce the unit of work calls needed in the applications.
This change also lead to keeping the units of work in a tree rather
than in a list as before.

      The units of work created by the application programs in
PM(...