InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

Replicating Non-Database Objects

IP.com Disclosure Number: IPCOM000237942D
Publication Date: 2014-Jul-23
Document File: 5 page(s) / 165K

Publishing Venue

The IP.com Prior Art Database


A method and system is disclosed for replicating non-database objects.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 36% of the total text.

Page 01 of 5

Replicating Non -

Disclosed is a method and system for replicating non-database objects. In a grid/cloud of multiple servers, operations such as, but not limited to, Data Manipulation Language (DML) and Data Definition Language (DDL) operations can be automatically replicated. The method and system can also replicate non-database objects with changes to a schema. To match up with the schema changes, external files can include new versions of executable programs or new scripts. As the schema changes are made and propagated to multiple target nodes within a grid, executable programs/scripts are also propagated. The method and system can also be used to load files and external files

which are used to support external tables.

To implement the replication of non-database objects, the fact that Enterprise Replication (ER) utilizes a streamwrite function and a streamread function to replicate a User Defined Type (UDT) is utilized. The UDT enables a user to create special database objects that extend basic data types of integers, characters and dates, for example. One such special database object, for example, is a shape object. By implementing the streamwrite function, which copies an external file into a queue and streams the elements of the UDT, the method and system disclosed herein is able to transfer content of the external file to the target nodes. On the target nodes, the method and system can write the file to the target location as part of a stream read logic.

The UDT may be called "ifmx_er_extfile." In addition to the file's path name, the UDT contains status flags, an error field, a grid identifier (id), a user name that created a request, and an optional output path name. The object is stored in a row as a varying-length character data which can expand up to 8000 bytes. The status item in the UDT is used to indicate if the target is successful or not in creating and copying the file. Thus, the status item is used to keep track of the success/failure of 'apply' so that an ACK or NACK status can be reported. The user can use the grid_copy(


) command to request the replication of a file across the grid. Since the grid has nodes, the grid defines targets for the file.

Internally, a grid_copy command can verify that the file exists, create a grid_command, and insert a row in a grid_copy table. The definition of the grid_copy table is as follows:

create table grid_copy {

gcpy_source integer,

{ Source node }

gcpy_stmtid integer,

{ statement id }

gcpy_gridid integer,

{ grid ID }

gcpy_files ifmx_er_extfile { file to replicate }


-Database Objects

Database Objects

Page 02 of 5


Streaming methods of the type ifmx_er_extfile are responsible for the replication of the external file. When ER is copying an inserted row into a queue on a source, the streamwrite function for the UDT can be invoked. The stream for the ifmx_er_extfile has a series of markers which identify the next bit of data. The data in turn is transmitted as varying-len...