Browse Prior Art Database

Resolve Dead Lock Problem During Multiple Users Updating

IP.com Disclosure Number: IPCOM000102417D
Original Publication Date: 1990-Nov-01
Included in the Prior Art Database: 2005-Mar-17
Document File: 2 page(s) / 63K

Publishing Venue

IBM

Related People

Tate, BA: AUTHOR [+2]

Abstract

Disclosed is a new method for handling deadlock for interactive query solutions. In order to achieve an acceptable solution, the database manager should have a way to communicate back to the interactive application. In the OOPS (object-oriented programming system) environment, the database may send messages to the the user to perform certain tasks such as "display a message" or "update a record on the screen". Alternately, message passing can be simulated in the current non-OOPS environment by passing function addresses from the application to the database so the database may call the application as needed.

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

Resolve Dead Lock Problem During Multiple Users Updating

       Disclosed is a new method for handling deadlock for
interactive query solutions.  In order to achieve an acceptable
solution, the database manager should have a way to communicate back
to the interactive application.  In the OOPS (object-oriented
programming system) environment, the database may send messages to
the the user to perform certain tasks such as "display a message" or
"update a record on the screen".  Alternately, message passing can be
simulated in the current non-OOPS environment by passing function
addresses from the application to the database so the database may
call the application as needed.

      In order to use this method, users must register with the
database engine as browse or transaction model processors. This
solution will pertain to browse-type users only.  When registered as
a browser, transactions are assumed to be very short and will consist
of a user looking at a datum with possibilities of updating later.
When the Query Manager requests an X lock on a record through an
engine API, the engine API should include these 2 function addresses
- the function address which displays a certain message (Message
Informer) and the function address which updates the record on the
screen (Hot Linker).  With the availability of the new API, the
following solution may be applied.

      For browse-type users, when the user holds an S lock and
requests a X lock on a record thro...