Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
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
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|
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