GLOP Types | Global and Persistent Data | Teradata Vantage - 17.10 - GLOP Types - Advanced SQL Engine - Teradata Database

Teradata Vantage™ - SQL External Routine Programming

Product
Advanced SQL Engine
Teradata Database
Release Number
17.10
Release Date
July 2021
Content Type
Programming Reference
Publication ID
B035-1147-171K
Language
English (United States)

The GLOP type determines the persistence boundary of the GLOP data, based on particular database activity.

System GLOP

A system GLOP mapping is mapped by all members of a given set. All external routines that are members of the same named GLOP set share this memory mapping.

The modification attribute (read-only or read/write) that you set for system GLOP data has the following effect.

IF the modification attribute is … THEN …
read-only every external routine that is a member of the set is mapped with the same data. They all see the same context.

If the system GLOP consists of multiple pages, then different external routines can simultaneously map different pages of the system GLOP, enabling each routine with a way to see a part of the data that it is interested in.

read/write every external routine that is a member of the set on that one vproc sees the same changes made by any external routine that changes the data.

Different vprocs do not necessarily have the same data changes unless the external routine that changes the data makes the same changes on all vprocs.

For more information on the read-only and read/write modification attributes, see GLOP Modification Attributes.

For system GLOP data with a read/write modification attribute, the mapping attribute (normal or shared) that you set has the following effect.

IF the mapping attribute is … THEN …
normal different GLOP sets that map the same system data get separate mappings.
shared different GLOP sets that map the same system data get the same system GLOP mapping on a vproc.

For more information on the normal and shared mapping attributes, see GLOP Mapping Attributes.

Role GLOP

A role GLOP mapping is always associated with a particular role that the external routine is executing and is based on what was set up for the logged on user for a particular session.

IF … THEN …
a mapping exists for a given role and the session has its context set up to use the role the system maps the GLOP data for the given role.
the external routine runs in a context that does not have a role GLOP data mapping specified for the given role in the GLOP set nothing is mapped for the external routine.
the routine is set to run in a session that has role ALL set up nothing is mapped, because it is not possible to determine which role to use.
the session role is NONE or NULL nothing is mapped.

Role GLOP data mapping for a GLOP set is not session local, it is based on the role. So, if there are ten sessions and each of them uses the same role then those ten sessions share the same role GLOP data mapping in all external routines that are members of the same GLOP set. This is similar to the system GLOP mapping except that there is a separate mapping for each role in the GLOP set.

If other external routines are members of a different GLOP set and the same role is specified in both sets, those role mappings are independent. (This assumes that there is actually GLOP data that identifies a particular role as having a mapping for a particular GLOP set.)

The effect of the modification attributes of a role GLOP is similar to the effect of the modification attributes of a system GLOP.

IF the modification attribute is … THEN …
read-only all vprocs have identical role data for each role that has a GLOP definition. In addition, there is only one physical copy of read-only role GLOP data on a node.
read/write then the data can differ on different vprocs.

If you want several roles to map to the same data, then use the shared mapping attribute for those roles that map the same data and have them reference the same GLOP data.

For more information on the read-only and read/write modification attributes, see GLOP Modification Attributes. For more information on the normal and shared mapping attributes, see GLOP Mapping Attributes.

User GLOP

A user GLOP mapping is always associated with a particular logged on user ID. It is not associated with a proxy user but the underlying user for the proxy. All sessions that are logged onto the same user ID share the data for the specific user mapping provided they specified the same GLOP set. This works similarly to the role mapping. (For details, see Role GLOP.) This allows several sessions all logged onto the same user to share information inside of the external routines that are associated with that user GLOP set.

The mapping is always associated with the logged on user that executes the external routine, not the current authorization (which could be different). For example, if Joe creates an external stored procedure and Betty logs on and executes that external 'DEFINER' procedure, the current authorization is Joe. But, Betty is the logged on user and if there is GLOP data for user Betty, that is the one that gets mapped, not the GLOP data for user Joe.

Session GLOP

A session GLOP mapping is local to a particular session. Only that session can normally see the data. The data exists as long as the session is logged on. The data never survives past the logged on session. When a new session is started a new fresh copy from the specific GLOP data row for the set is obtained and mapped. The data is accessible to all external routines that execute within the session and the given GLOP set.

External routines that are members of different GLOP sets get different GLOP session mappings. Mappings are private to the session unless the shared mapping attribute is set.

IF the mapping attribute is … THEN …
normal different GLOP sets that map the same session read/write data get separate mappings.
shared different GLOP sets that map the same session read/write data get the same mappings.

GLOP changes made to read/write data are retained and visible for the next external routine using the same GLOP set.

For more information on the normal and shared mapping attributes, see GLOP Mapping Attributes.

Transaction GLOP

A transaction GLOP mapping is local to a session and transaction. A transaction GLOP mapping survives as long as a transaction survives. This GLOP type is only available to external routines executing on an AMP vproc. It is not available or relevant to PE vprocs because many external routines actually execute outside of a transaction, so even if mapping were provided it would not be available a lot of the time.

When a transaction terminates, the mapping is lost.

When a transaction starts, a new fresh copy from the specific GLOP data for the set is obtained and mapped.

Request GLOP

A request GLOP mapping is local to a session, transaction and request combination. This GLOP type is only available to external routines executing on an AMP vproc. A request GLOP mapping has potentially the shortest life. It is created when the mapping so specifies at the beginning of a request and survives for the duration of the request. All external routines executed within the same request and GLOP membership see the same mapping for the session in question. At the end of the request the mapping is discarded. A new request gets a new mapping from the GLOP data associated with the GLOP membership.

Because requests are potentially very short running, using this GLOP type requires some very careful thought. If not careful, this mode could substantially increase the running time of a transaction, for example, a set of small requests encountered in TPUMP.

External Routine GLOP

An external routine GLOP mapping is associated with a specific routine. It is always local to that routine, but it crosses all session boundaries. In other words, no matter in what session the external routine executes in, the mapping is always available. If there are several instances of the external routine with the same name running in different sessions they all look at the same GLOP data for this GLOP type. Changes made to it are seen by all future callers. The GLOP data is retained until the next system restart or a forced remove by a change of the GLOP.