GRS

What's a GRS?

Global Resource System (GRS) is a JEM component responsible for enabling fair access to serially reusable computing resources, such as datasets or custom virtual locks. Jobs (or programs using java API) can request:

• exclusive access to a resource (which means that job and all subsequent requesting jobs are blocked until that job is given access to the resource), usually requested when a job needs to update the resource
• shared access (which means that multiple jobs can be given access to the resource), usually requested when a job only needs to query the state of the resource

GRS manages all requests in FIFO (first in/first out) order.

GRS uses (quoted from Readers&Writer definition in Wikipedia) a readers-writer (RW) or shared-exclusive lock (also known as a multiple readers/single-writer lock or multi-reader lock) is a synchronization primitive that solves one of the readers-writers problems.

An RW lock allows concurrent access for read-only operations, while write operations require exclusive access. This means that multiple threads can read the data in parallel but an exclusive lock is needed for writing or modifying data. When a writer is writing the data, all other writers or readers will be blocked until the writer is finished writing.

How JEM uses GRS

JEM uses Hazelcast capabilities to map all resources requests from all JEM nodes.

To activate GRS, you should configure a specific JEM node inside JEM environment configuration file, because all JEM nodes must use GRS node to be consistent. It's enough to change the OOTB configuration, setting at node element, the class org.pepstock.jem.grs.GrsNode.

All resources are defined and locked before to call program which needs resources, (at job or step or task level). All files are candidated out-of-the-box for locking, by a specific syntax to use in the JCL language (all OOTB JCL languages implement this feature, by data descriptors).

GRS works in READ (shared access) and/or WRITE (exclusive access) modes, so the following table explains how JEM manages different dispositions on files translating in only 2 types (read and write):

Data description disposition	GRS lock
NEW	WRITE
MOD	WRITE
OLD	WRITE
SHR	READ

When a JEM node crashes, the coordinator will unlock all resources previously blocked by a job which was running in JEM node.

A sample about a resources locked display is following:

Resource: "gdg.jemtest"
Member-Name          Requestor-Id                            Read/Write Requestor            
10.10.10.10:5710     0000000000000000001-0000001348050026751 WRITE      JOB1                 

 Resource: "cnf.xml"
Member-Name          Requestor-Id                            Read/Write Requestor            
10.10.10.10:5710     0000000000000000001-0000001348050026751 READ       JOB1