Browse Prior Art Database

Serialization Locks in a Share-Nothing Multiple Node RDBMS

IP.com Disclosure Number: IPCOM000123555D
Original Publication Date: 1999-Jan-01
Included in the Prior Art Database: 2005-Apr-05
Document File: 3 page(s) / 156K

Publishing Venue

IBM

Related People

Bird, PM: AUTHOR [+2]

Abstract

This disclosure describes a method for the serializing of processing requests in a share-nothing multiple node system by using standard RDBMS (Relational Database Management System) locks. Serialization in a multiple node environment is required to minimize network traffic and eliminate redundant processing of identical requests. In a shared nothing multiple node system with no shared resources, traditional serialization techniques such as latches or semaphores are subject to cross-node "deadlock" situations. The use of the existing RDBMS lock technology ensures appropriate serialization while at the same time providing cross-node deadlock resolution and other desired features of RDBMS locking in a multi-node environment.

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

Serialization Locks in a Share-Nothing Multiple Node RDBMS

   This disclosure describes a method for the serializing
of processing requests in a share-nothing multiple node system by
using standard RDBMS (Relational Database Management System) locks.
Serialization in a multiple node environment is required to minimize
network traffic and eliminate redundant processing of identical
requests.  In a shared nothing multiple node system with no shared
resources, traditional serialization techniques such as latches or
semaphores are subject to cross-node "deadlock" situations.  The use
of the existing RDBMS lock technology ensures appropriate
serialization while at the same time providing cross-node deadlock
resolution and other desired features of RDBMS locking in a
multi-node environment.

   In a multiple node system the network performance can be
a crucial aspect of performance.  If a network is flooded with
requests to transfer information, the performance of the system may
downgrade.  Hence when designing a multiple node system it is
necessary to ensure that transfer of the information across the
network is, in fact, necessary.

   In a multiple node database, it is often necessary to send
a request from one node to another to send back some specific
information. Very often a number of applications need the same
information; if all these applications were to request this
information be sent over the network at the same time the network
would have to send this information multiple times to different
applications, when in fact only one send would be sufficient.

   Hence to avoid unnecessary demands on the network, it
would be desirable to ensure that in this situation all identical
requests were serialized.  That is, only one request for the same
information would be allowed to be sent over the network at the same
time.  Once the information is delivered across the network to the
requesting node, then the other waiting applications would be allowed
to proceed and noting that the desired information is available at
the local node would avoid requesting the network transfer of that
same information.

   Traditional mechanisms for serializing include the use of
semaphores or latches.  However in a share-nothing multi-node
environment where there are no shared resources between the nodes,
using these methods is problematic.  Consider an application (A) at a
node (node 1) which secures the semaphore or the latch and requests
information be sent from another node, node 2.  In the course of
retrieving the information at the node 2 another serializing
mechanism may need to be secured, which in turn may already be
secured by another application (B).  If application B itself is
waiting for a resource that is already secured by application A, then
we have a cross-node "deadlock" situation that needs to be resolved
in order for either application to continue.  More complicated
"deadlock" situations involving multiple applications and mult...