بدترین اختلال کوبرنتیزی که مدام می‌بینم، از کار افتادن یک نود نیست. یک پایگاه‌داده‌ی کُند است، یک پروب liveness که با همان پایگاه‌داده حرف می‌زند، و کلاستری که بعد هر پادی را که هنوز کار مفید می‌کرد می‌کُشد.

liveness یعنی «این برنامه سالم است» نیست. یعنی «این فرایند آن‌قدر گیر کرده که کوبرنتیز باید خلاصش کند». اگر این اسلحه را به سمت یک وابستگی بگیرید، کل ناوگان را خواهید زد.

در بازبینی کد هنوز می‌بینم که @Transactional مثل یک دعای خیر به کار می‌رود: رویش بگذار روی یک متد، و پایگاه‌داده سر به راه می‌شود. نمی‌شود. اسپرینگ وقتی تراکنشی را شروع می‌کند که یک پروکسی فراخوانی ورودی را بگیرد. اگر فراخوانی هرگز به پروکسی نرسد، نه تراکنشی دارید، نه rollbackی، و در عوض یک باگ بسیار گیج‌کننده در محیط عملیاتی خواهید داشت.

آنچه باور داشتم ← آنچه حالا می‌کنم

قبلاً «محض احتیاط» روی هر متد سرویس کمی @Transactional می‌پاشیدم. حالا آن را روی همان یک متدی می‌گذارم که مرز مورد کاربرد است، تستی می‌نویسم که rollback را اثبات کند، و فراخوانی‌های خصوصی درون یک کلاس را نشانه‌ی بو می‌دانم.

نقشه‌ای از اینکه واقعاً چطور نرم‌افزار بک‌اند را اجرا می‌کنم: جاوا روی JVM، اسپرینگ به‌عنوان لایه‌ی برنامه، و کوبرنتیز به‌عنوان جایی که برنامه در آن زندگی می‌کند. از اینجا شروع کنید، بعد سراغ یادداشتی بروید که با مسئله‌ی پیش روی شما می‌خواند.

این یک فهرست آموزشی نیست. این ترتیبی است که یک هم‌تیمی را بعد از یک حادثه از آن عبور می‌دهم.

اگر تازه اینجا آمده‌اید

1. @Transactional اسپرینگ آن چیزی نیست که فکر می‌کنید — اینکه تراکنش‌ها واقعاً کجا شروع می‌شوند، و چرا متدی که روی this متد دیگری را صدا می‌زند بی‌سروصدا هیچ کاری نمی‌کند.
2. زنده‌بودن با سالم‌بودن فرق دارد — آن اختلال کوبرنتیز که شبیه حلقه‌ی کرش به نظر می‌رسد ولی از یک وابستگی کُند شروع شده است.
3. درس‌های قابلیت اطمینان از SQLite — چرا ابزاری که مسئله‌های بیشتری حل می‌کند تا بسازد، در محیط عملیاتی ماندگار می‌شود.

دوره‌ی جاوا مسیر بلندتر است، برای وقتی که بخواهید این پشته را با من بنویسید، نه فقط درباره‌اش بخوانید.