ඔබත් සොෆ්ට්වෙයා සංවර්ධනයේ වැඩ කරනවානම්, පරණ පද්ධති වලින් බිඳ වැටෙන බග් ගාථා ගැන අසා තියෙනවා. මේකත් ඒ අයුරින්ම, ජෙරි කියන පුරාණ Java යෙදුමක ඇතිවූ ගැටලු කතාවයි. Java 8 යුගයේ ලියලා, උඩු-දත්ත ලබාගෙන DB2 දත්ත ගබඩාවට තබන එකම කාර්යයක් කරන ලද ජෙරි, කාලයත් සමඟ වැඩ බහුලවී, අර්ථයක් නැති අතිරේක කාර්යයන් ගෙන ආහ. ඒක නිසා, කාර්ය බර වැඩිවූ විට, එහි අඩුපාඩු හෙළිවී ගියා.
මුලින්ම පෙනුනේ DB2 සම්බන්ධතා පූල් එක පිරී, HikariCP හි සීමිත සම්බන්ධතා ගණන නිසා "connection pool not available" යන දෝෂ පණිවුඩය පෙනීම. කණ්ඩායම පූල් විශාල කරමින්, කාල සීමා (timeout) සකස් කරමින්, "zombie threads" ඉවත් කරමින් අත්හදා බැලුවා. කෙටි කාලයකට වැඩි වේගයක් ලැබුනත්, ගැටලුව පූර්ණයෙන් නාස්ති නොවීය.
දෙවැනි වරට, වැඩි පරීක්ෂණ දත්ත සහ අළුත් ලොඩ් එකක් යොදා බලද්දී, ජෙරි තවත් අධික පරිමාවක query ලැබී, තවත් timeout, deadlock ගැටළු පෙන්වීය. එය තාවකාලිකව සලස්වූ පසුද, කිහිප සතිකින් නැවත පැමිණෙමින්, නව තත්ත්වය පවා පසුබැසීමක් විය. එම නිසා, සියලුම තාක්ෂණික කණ්ඩායම් එකට රැස්වී, බහු-මාන විශ්ලේෂණයක් කළා. නමුත් එක් එක් තත්ත්වය වෙනත් තත්ත්වයක් හෝ නිරාකරණය කළා, ඒත් ඒ සියල්ලම නිවැරදි පිළිතුරක් නොවීය.
ශ්රී ලංකාවට ඇති වැදගත්කම
- සැලසුම් කළමනාකරණය: පරණ පද්ධති වල අලුත් වැඩ එක් කිරීමේදී, සම්පූර්ණ විශ්ලේෂණයක් නොකළහොත්, පසුබැසීමක් ඇති විය හැක.
- දත්ත සම්බන්ධතා: HikariCP වැනි connection pool භාවිතයේ timeout සහ pool size සැකසුම වැදගත්. එය Sri Lankan startups වල scalability එකට මූලිකය.
- ඉන්ටර්-දල වාර්තා: බහු‑කණ්ඩායම් එක්ව debug කිරීමේ පද්ධතියක් (observability) හඳුන්වා දීම, ශ්රී ලංකාවේ software house වල නිෂ්පාදන වේගය වැඩි කරයි.
- ඉගෙනුම් අවස්ථා: මෙවැනි “real‑world” බග් කතා, දැනුම් ප්රචාරණය සහ junior developers සඳහා වටිනා case study එකක්.
අවසානයේ, ජෙරිගේ ගැටළු සම්පූර්ණයෙන් නාස්ති නොවූවත්, ඒ මගින් අපට ලැබුනු පාඩම් වඩාත් පරිපූර්ණ පද්ධති සැලසුමක්, හොඳ observability, සහ අනාගතයේදී වඩාත් ස්ථායිකරණය කළ හැකි architecture එකක් ගොඩනැගීමට මඟ පෙන්වයි.
එම නිසා, පරණ පද්ධති නවීකරණය කරන සෑම සංවර්ධකයෙකුටම මේ කතාව මතක තබා, අධික බරක් එක් නොකර, සැලසුම්‑දෘශ්යය සහ performance‑monitoring‑වලට ප්රමුඛත්වය දිය යුතුය.
