Browse Prior Art Database

Multi-Arm Journaling

IP.com Disclosure Number: IPCOM000119590D
Original Publication Date: 1991-Feb-01
Included in the Prior Art Database: 2005-Apr-01
Document File: 5 page(s) / 222K

Publishing Venue

IBM

Related People

Dean, RD: AUTHOR [+2]

Abstract

Disclosed is a description of a high concurrency software algorithm that increases the throughput of the Write Ahead Logging function on the AS/400* by controlling the output of log data to multiple direct access storage device (DASD) actuators left at the disposal of the log function.

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

Multi-Arm Journaling

      Disclosed is a description of a high concurrency software
algorithm that increases the throughput of the Write Ahead Logging
function on the AS/400* by controlling the output of log data to
multiple direct access storage device (DASD) actuators left at the
disposal of the log function.

      In order to get overlap between CPU and the writing of journal
entries, the Journal function needs a mechanism by which a waiting
invoker can be signalled when a write upon which it depends has
completed.  This mechanism makes it possible for the last invoker in
a bundle to wait for the completion of the write without also
maintaining exclusive access to the Journal object.  Since this last
invoker no longer needs the exclusive access, other invokers can be
depositing entries into subsequent bundles while the previously
started bundle write is being performed.  The ability to signal an
invoker about the completion of a write is also a new capability on
the AS/400, available in Release 3.0.

      To take even more advantage of this ability to populate a
journal entry bundle after a write for a previous bundle has been
started, the Journal function expands this ability to have writes
started for more than one previous bundle while still being able to
populate a last/current bundle. This is where the multi-arm feature
of the new Journal function comes in.  Just starting several writes
on a single DASD Actuator (Arm) would result in a guaranteed queuing
of write requests.  It is more efficient to start the write requests
on separate arms so that they all have a chance of being processed
concurrently.  This way, CPU is overlapped with more than one
outstanding write request.  The combination of multiple bundles of
journal entries being written at the same time, not just queued to be
written, and the fact that the Journal object is free to be accessed
by other invokers, greatly improves the overall throughput of
changing data items that are being journaled to the same Journal
object.

      IMPLEMENTATION OF MULTI-ARM JOURNALING
AB JOURNAL OBJECT DESIGN The first major problem to solve was the
construction of a Multi- Arm Journal object.  The object is actually
made up of two separate objects, a Journal Port and a Journal Space.
Data item objects that are being journaled to the Journal object are
kept track of in the Journal Port.  The actual journal entries are
kept in the Journal Space.

      See the figure for the linkages between the journal objects.
AB JOURNAL SPACE DESIGN A Journal Space will use as many arms as are
available in the storage pool in which it was created.  If it were
created in a three- arm storage pool, then it will be a three-arm
Journal Space.  To keep track of the current insertion state of each
of the arms of a Journal Space, a table of arm state values is kept
in the header of the Journal Space.  This is known as the Arm Table.
It has one slot per Arm and, therefore, could...