ਡਿਵੈਲਪਰ ਹੁਣ ਸਟੇਟ ਫਾਈਲਾਂ ਦੇ ਉੱਪਰ ਲਿਖੇ ਜਾਣ ਜਾਂ ਲੁਕੀਆਂ ਹੋਈਆਂ ਫਾਈਲਾਂ ਦੇ ਟਕਰਾਉਣ ਦੇ ਡਰ ਤੋਂ ਬਿਨਾਂ ਇੱਕੋ ਸਮੇਂ ਕਈ ਕੋਡਿੰਗ-ਏਜੰਟ ਸੈਸ਼ਨ ਸ਼ੁਰੂ ਕਰ ਸਕਦੇ ਹਨ। ਇੱਕ ਸਲਾਹਕਾਰ (advisory) “share-nothing” ਪੈਟਰਨ ਹਰੇਕ ਏਜੰਟ ਦੇ ਵਰਕਸਪੇਸ ਨੂੰ ਵੱਖਰਾ ਕਰਦਾ ਹੈ ਅਤੇ ਸੰਭਾਵੀ ਟਕਰਾਅ ਬਾਰੇ ਚੇਤਾਵਨੀ ਦਿੰਦਾ ਹੈ। ਇਹ ਪਹੁੰਚ ਸਖ਼ਤ ਲੌਕਾਂ (hard locks) ਦੀ ਜਗ੍ਹਾ ਇੱਕ ਹਲਕੀ ਰਜਿਸਟਰੀ ਦੀ ਵਰਤੋਂ ਕਰਦੀ ਹੈ ਜੋ ਕੰਮ ਦੇ ਟਕਰਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਹੀ ਉਸਦੀ ਸੂਚਨਾ ਦਿੰਦੀ ਹੈ, ਜਿਸ ਨਾਲ ਸੈਸ਼ਨ ਕ੍ਰੈਸ਼ ਹੋਣ 'ਤੇ ਵੀ ਪਾਈਪਲਾਈਨਾਂ ਚਲਦੀਆਂ ਰਹਿੰਦੀਆਂ ਹਨ।
ਪੈਰਲਲ ਏਜੰਟ ਕਿਉਂ ਮੁਸ਼ਕਲ ਪੈਦਾ ਕਰਦੇ ਹਨ
ਇੱਕ ਸਿੰਗਲ ਰਿਪੋਜ਼ਟਰੀ ਵਿੱਚ ਇੱਕ ਤੋਂ ਵੱਧ ਆਟੋਮੇਟਡ ਕੋਡਿੰਗ ਸਹਾਇਕਾਂ (coding assistants) ਨੂੰ ਚਲਾਉਣ ਨਾਲ ਕੋਡ ਜਨਰੇਸ਼ਨ, ਟੈਸਟਿੰਗ, ਜਾਂ ਰੀਫੈਕਟਰੀੰਗ ਦੀ ਰਫ਼ਤਾਰ ਵਧ ਜਾਂਦੀ ਹੈ। ਅਸਲ ਵਿੱਚ, ਦੋ ਮੁੱਖ ਸਮੱਸਿਆਵਾਂ ਸਾਹਮਣੇ ਆਉਂਦੀਆਂ ਹਨ।
- ਸਟੇਟ ਕਰੱਪਸ਼ਨ (State corruption) – ਦੋ ਏਜੰਟ ਇੱਕੋ ਸਟੇਟ ਫਾਈਲ ਵਿੱਚ ਲਿਖਦੇ ਹਨ; ਬਾਅਦ ਵਾਲਾ ਲਿਖਣ ਦਾ ਕੰਮ ਪਹਿਲੇ ਵਾਲੇ ਨੂੰ ਮਿਟਾ ਦਿੰਦਾ ਹੈ, ਜਿਸ ਨਾਲ ਕੀਤੀ ਗਈ ਪ੍ਰਗਤੀ ਖਤਮ ਹੋ ਜਾਂਦੀ ਹੈ।
- ਫਾਈਲ ਟਕਰਾਅ (File collision) – ਦੋ ਏਜੰਟ ਇੱਕ-ਦੂਜੇ ਤੋਂ ਅਣਜਾਣ ਹੋ ਕੇ ਇੱਕੋ ਸੋਰਸ ਫਾਈਲ ਨੂੰ ਐਡਿਟ ਕਰਦੇ ਹਨ। ਇਹ ਟਕਰਾਅ ਬਾਅਦ ਵਿੱਚ ਉਦੋਂ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ ਜਦੋਂ 'diff' ਵੱਖ-ਵੱਖ ਤਬਦੀਲੀਆਂ ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ।
ਇਹ ਦੋਵੇਂ ਸਮੱਸਿਆਵਾਂ ਡਿਵੈਲਪਰ ਦਾ ਸਮਾਂ ਬਰਬਾਦ ਕਰਦੀਆਂ ਹਨ ਅਤੇ ਅਜਿਹੇ ਬੱਗ (bugs) ਪੈਦਾ ਕਰ ਸਕਦੀਆਂ ਹਨ ਜਿਨ੍ਹਾਂ ਨੂੰ ਲੱਭਣਾ ਮੁਸ਼ਕਲ ਹੁੰਦਾ ਹੈ।
“share nothing” ਨਿਯਮ
ਮੁੱਖ ਵਿਚਾਰ ਸਰਲ ਹੈ: ਹਰੇਕ ਏਜੰਟ ਨੂੰ ਡਿਸਕ 'ਤੇ ਆਪਣਾ ਨਿੱਜੀ ਸਕ੍ਰੈਚਪੈਡ (scratchpad) ਮਿਲਦਾ ਹੈ ਅਤੇ ਉਹ ਸਿਰਫ਼ ਉਸੇ ਸੈਸ਼ਨ ਨਾਲ ਸਬੰਧਤ ਫਾਈਲਾਂ ਵਿੱਚ ਲਿਖਦਾ ਹੈ। ਹਰੇਕ ਬ੍ਰਾਂਚ ਲਈ ਸਿਰਫ਼ ਇੱਕ ਜਾਣਬੁੱਝ ਕੇ ਸਾਂਝੀ ਕੀਤੀ ਗਈ ਫਾਈਲ ਦੀ ਇਜਾਜ਼ਤ ਹੈ, ਅਤੇ ਇਹ “last-writer-wins” ਨਿਯਮ ਦੀ ਪਾਲਣਾ ਕਰਦੀ ਹੈ—ਜੋ ਵੀ ਏਜੰਟ ਆਖਰੀ ਵਾਰ ਲਿਖਦਾ ਹੈ, ਉਹੀ ਅੰਤਿਮ ਸਮੱਗਰੀ ਤੈਅ ਕਰਦਾ ਹੈ।
ਇੱਕ presence layer ਹਰੇਕ ਸਰਗਰਮ ਸੈਸ਼ਨ ਨੂੰ ਟ੍ਰੈਕ ਕਰਦੀ ਹੈ:
- ਬ੍ਰਾਂਚ ਦਾ ਨਾਮ
- ਵਰਤੀਆਂ ਜਾ ਰਹੀਆਂ ਫਾਈਲਾਂ ਦੀ ਸੂਚੀ
- ਆਖਰੀ ਗਤੀਵਿਧੀ ਦਾ ਟਾਈਮਸਟੈਂਪ (Timestamp)
ਜਦੋਂ ਕੋਈ ਨਵਾਂ ਸੈਸ਼ਨ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਇਹ ਰਜਿਸਟਰੀ ਦੀ ਜਾਂਚ ਕਰਦਾ ਹੈ। ਜੇਕਰ ਕੋਈ ਹੋਰ ਸੈਸ਼ਨ ਪਹਿਲਾਂ ਹੀ ਉਸੇ ਫਾਈਲ 'ਤੇ ਕੰਮ ਕਰ ਰਿਹਾ ਹੈ, ਤਾਂ ਡਿਵੈਲਪਰ ਨੂੰ ਕੋਈ ਵੀ ਕੰਮ ਸ਼ੁਰੂ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਚੇਤਾਵਨੀ ਮਿਲ ਜਾਂਦੀ ਹੈ।
Advisory ਬਨਾਮ blocking ਲੌਕਸ
ਰਵਾਇਤੀ ਲੌਕ ਫਾਈਲਾਂ ਇੱਕ ਬੰਦ ਰਸਤੇ ਵਾਂਗ ਕੰਮ ਕਰਦੀਆਂ ਹਨ: ਇੱਕ ਵਾਰ ਲੌਕ ਲੱਗ ਜਾਣ ਤੋਂ ਬਾਅਦ, ਕੋਈ ਵੀ ਹੋਰ ਪ੍ਰੋਸੈਸ ਉਦੋਂ ਤੱਕ ਉਡੀਕ ਕਰਦਾ ਹੈ ਜਦੋਂ ਤੱਕ ਲੌਕ ਖੁੱਲ੍ਹ ਨਹੀਂ ਜਾਂਦਾ। ਜੇਕਰ ਮਾਲਕ ਸੈਸ਼ਨ ਕ੍ਰੈਸ਼ ਹੋ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਲੌਕ ਅਨੰਤ ਕਾਲੇ ਸਮੇਂ ਲਈ ਰਹਿ ਸਕਦਾ ਹੈ, ਜਿਸ ਨਾਲ ਪੁਰਾਣੀਆਂ ਲੌਕ ਫਾਈਲਾਂ ਨੂੰ ਮੈਨੂਅਲੀ ਲੱਭਣ ਦੀ ਲੋੜ ਪੈਂਦੀ ਹੈ।
Advisory ਮਾਡਲ ਵਧੇਰੇ ਨਰਮ ਹੈ। ਇਹ ਸੰਭਾਵੀ ਟਕਰਾਅ ਦਾ ਪਤਾ ਲੱਗਣ 'ਤੇ ਚੇਤਾਵਨੀ ਜਾਰੀ ਕਰਦਾ ਹੈ ਪਰ ਨਵੇਂ ਸੈਸ਼ਨ ਨੂੰ ਰੋਕਦਾ ਨਹੀਂ ਹੈ। ਜੇਕਰ ਰਜਿਸਟਰੀ ਐਂਟਰੀ ਪੁਰਾਣੀ ਹੈ—ਯਾਨੀ ਕਿ ਜਿਸ ਪ੍ਰੋਸੈਸ ਨੇ ਇਸਨੂੰ ਬਣਾਇਆ ਸੀ ਉਹ ਹੁਣ ਮੌਜੂਦ ਨਹੀਂ ਹੈ—ਤਾਂ ਵੀ ਸਿਸਟਮ ਸਿਰਫ਼ ਚੇਤਾਵਨੀ ਦਿੰਦਾ ਹੈ, ਅਤੇ ਡਿਵੈਲਪਰ ਨੂੰ ਇਹ ਫੈਸਲਾ ਲੈਣ ਦਿੰਦਾ ਹੈ ਕਿ ਅੱਗੇ ਵਧਣਾ ਹੈ ਜਾਂ ਨਹੀਂ।
ਇਸ ਪੈਟਰਨ ਨੂੰ ਕਿਵੇਂ ਲਾਗੂ ਕਰਨਾ ਹੈ
- ਲਿਖਣ ਵਾਲੇ ਅਨੁਸਾਰ ਸਟੇਟ ਨੂੰ ਵੰਡੋ (Partition state by writer) – ਹਰੇਕ ਏਜੰਟ ਨੂੰ 임ਤਿਯਾ ਫਾਈਲਾਂ (temporary files) ਅਤੇ ਸਟੇਟ ਲਈ ਆਪਣੀ ਵੱਖਰੀ ਡਾਇਰੈਕਟਰੀ ਦਿਓ। ਸਾਂਝੀਆਂ ਫਾਈਲਾਂ ਨੂੰ ਸਿਰਫ਼ ਅਸਲ ਗਲੋਬਲ ਡੇਟਾ ਲਈ ਰੱਖੋ ਅਤੇ ਉੱਥੇ ਹੀ “last-writer-wins” ਨਿਯਮ ਲਾਗੂ ਕਰੋ।
- ਸ਼ੁਰੂਆਤ ਵੇਲੇ ਜਾਗਰੂਕਤਾ ਲਿਆਓ (Inject awareness at launch) – ਏਜੰਟ ਸ਼ੁਰੂ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ, presence registry ਨੂੰ ਪੜ੍ਹੋ ਅਤੇ ਮੰਗੀ ਗਈ ਫਾਈਲ ਦੀ ਸੂਚੀ ਦੀ ਤੁਲਨਾ ਮੌਜੂਦਾ ਐਂਟਰੀਆਂ ਨਾਲ ਕਰੋ। ਜੇਕਰ ਕੋਈ ਓਵਰਲੈਪ (overlap) ਮਿਲਦਾ ਹੈ, ਤਾਂ ਕੰਮ ਰੋਕ ਦਿਓ ਜਾਂ ਚੇਤਾਵਨੀ ਦਿਓ।
- ਪੜ੍ਹਨ ਸਮੇਂ ਜੀਵਨਤਾ ਦੀ ਜਾਂਚ ਕਰੋ (Verify liveness at read time) – ਰਜਿਸਟਰੀ ਐਂਟਰੀ ਦੀ ਜਾਂਚ ਕਰਦੇ ਸਮੇਂ, ਇਹ ਦੇਖੋ ਕਿ ਕੀ ਰਿਕਾਰਡ ਕੀਤੀ ਗਈ ਪ੍ਰੋਸੈਸ ID ਅਜੇ ਵੀ OS 'ਤੇ ਚੱਲ ਰਹੀ ਹੈ। ਮਰ ਚੁੱਕੇ ਪ੍ਰੋਸੈਸਾਂ ਨਾਲ ਸਬੰਧਤ ਐਂਟਰੀਆਂ ਨੂੰ ਹਟਾ ਦਿਓ।
- Blocking ਦੀ ਬਜਾਏ Advisory ਨੂੰ ਤਰਜੀਹ ਦਿਓ – ਡਿਵੈਲਪਰਾਂ ਨੂੰ ਕੰਟਰੋਲ ਰੱਖਣ ਦਿਓ। ਇੱਕ ਚੇਤਾਵਨੀ ਉਨ੍ਹਾਂ ਨੂੰ ਜਾਰੀ ਰੱਖਣ, ਰੋਕਣ ਜਾਂ ਰੱਦ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦੀ ਹੈ, ਜਿਸ ਨਾਲ ਡੈੱਡਲੌਕ (deadlock) ਤੋਂ ਬਚਿਆ ਜਾ ਸਕਦਾ ਹੈ।
- ਇੰਤਜ਼ਾਰ ਦੀ ਸਥਿਤੀ ਨੂੰ ਟ੍ਰੈਕ ਕਰੋ (Track waiting states) – ਜਦੋਂ ਬਹੁਤ ਸਾਰੇ ਏਜੰਟ ਸਰਗਰਮ ਹੁੰਦੇ ਹਨ, ਤਾਂ ਡਿਵੈਲਪਰ ਦਾ ਧਿਆਨ ਹੀ ਰੁਕਾਵਟ ਬਣ ਜਾਂਦਾ ਹੈ। ਇਹ ਦਿਖਾਓ ਕਿ ਕਿਹੜੇ ਏਜੰਟ ਮਨੁੱਖੀ ਇਨਪੁਟ ਦੀ ਉਡੀਕ ਕਰ ਰਹੇ ਹਨ ਤਾਂ ਜੋ ਕੰਮ ਨੂੰ ਦੁਬਾਰਾ ਤਰਜੀਹ ਦਿੱਤੀ ਜਾ ਸਕੇ।
ਇਹ ਸਭ ਕੁਝ JSON ਫਾਈਲਾਂ ਦੀ ਇੱਕ ਸਾਧਾਰਨ ਡਾਇਰੈਕਟਰੀ ਨਾਲ ਬਣਾਇਆ ਜਾ ਸਕਦਾ ਹੈ; ਕਿਸੇ ਬਾਹਰੀ ਡੇਟਾਬੇਸ ਜਾਂ ਮੈਸੇਜ ਬੱਸ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ। ਸਰਲ ਸਟੋਰੇਜ ਫਾਰਮੈਟ ਸਿਸਟਮ ਨੂੰ ਆਡਿਟ ਕਰਨਾ ਆਸਾਨ ਬਣਾਉਂਦਾ ਹੈ ਅਤੇ ਵੱਖ-ਵੱਖ ਮਾਹੌਲਾਂ (environments) ਵਿੱਚ ਪੋਰਟੇਬਲ ਬਣਾਉਂਦਾ ਹੈ।
ਜੋਖਮ ਅਤੇ ਵਿਰੋਧੀ ਨੁਕਤੇ
ਕੁਝ ਟੀਮਾਂ ਦਾ ਤਰਕ ਹੋ ਸਕਦਾ ਹੈ ਕਿ ਇੱਕ ਹਾਰਡ ਲੌਕ ਸੁਰੱਖਿਆ ਦੀ ਗਾਰੰਟੀ ਦਿੰਦਾ ਹੈ: ਕੋਈ ਵੀ ਦੋ ਏਜੰਟ ਕਦੇ ਵੀ ਇੱਕੋ ਫਾਈਲ ਵਿੱਚ ਨਹੀਂ ਲਿਖ ਸਕਦੇ। ਪਰ ਇਸਦਾ ਨੁਕਸਾਨ ਇਹ ਹੈ ਕਿ ਲਚਕਤਾ (resilience) ਘਟ ਜਾਂਦੀ ਹੈ—ਕ੍ਰੈਸ਼ ਹੋਏ ਸੈਸ਼ਨ ਅਜਿਹੇ ਲੌਕ ਛੱਡ