Дякую!
О, то чекаю від вас адаптацію статті в комікс, і читабельність підніметься і картіночки цікаві можуть бути)
Я дуже хотів зробити пояснення більш зрозумілим, тому часом тези повторюються, але схоже це мене і погубило)
Я планував зробити одну статтю по транзакціям, але коли написав це все зрозумів, що треба ділити, бо то ще навіть не половина)
По тексту, я ще можу відредагувати, певно трохи поспішив з постингом, дякую за зауваження, підкоректою обовʼязково!
А що саме вам не зрозуміло?
Насправді в мене були такі кейси на одному з проектів, але то було давно і вже не згадаю в чому там була проблема) Наскільки я памʼятаю з сіквенсами в хайбернейті були приколи, але може вже пофіксили)
Абстракція це завжди добре, але часом через неї важче або навіть неможливо використовувати деякий нативний функціонал) тому згадати варто, але краще най би воно працювало і без того) не завжди доцільно ставити зайву абстракцію, коли мова йде про продуктивність)
Дякую за уважність, підправив.
Саме так
Якщо ви про Epsilon GC, то його варто використовувати лише для тестування застосунку без впливу збирача сміття, навіть CMS депрікейтнули через те, що він не робив дефрагментацію ганяючись за продуктивністю і малими паузами. Тому якщо є потреба, то підбирайте збирач сміття під проект, без нього не стартуйте, бо забʼється памʼять з часом і все повалиться. Гляньте мою статтю саме по збирачах сміття, посилання на неї є на початку цієї статті.
Я б так не сказав, українське джава комʼюніті тільки росте. Може ви не там шукаєте) Гляньте @ukraine_java i @professional_software_wizard в телеграмі
Стаття вийшла доволі обширною, тому було прийнято рішення розділити її на декілька частин, результати продуктивності та тюнінг буде в наступній частині
Так з цього треба було починати)
Схоже тут я все таки помилився, G1GC досі збирач сміття за замовчуванням, ZGC просто тепер за замовчуванням Generational. Різні вендори можуть ставити різні дефолтні конфіги, тільки що перевірив на версії Oracle-23.0.2 G1GC дефолтний. Для Temurin-23.0.2 знову ж таки G1GC. Спробуйте перевірити саме jdk, не використовуючи докер.
Якщо alias-ids правильно впроваджені (без прив’язки до чутливих даних), їх використання в URL для RESTful API є хорошою практикою. Ви можете реалізувати як POST /transfers/{alias-id-1}/{alias-id-2}, так і POST /transfers із передачею alias-ids у тілі запиту, залежно від того, що більше відповідає вашій архітектурі. Але для максимальної безпеки краще залишати ідентифікатори в тілі запиту, особливо якщо мова йде про чутливі операції, як-от фінансові транзакції.
Але я би все таки радив робити через request body, як мінімум щоб не роздувати url та збільшити секʼюрність.
Краще не вказувати ці дані як path variables в url для більшої секʼюрності, безпечніше буде передавати через request body
Я ще часто використовую/стикаюся з
201 — все добре, ресурс створено
204 — все окей, але ніц не знайдено
405 — не той метод, дурнику
409 — назріває конфлікт, треба шось міняти
415 — що це за тип даних, мені таке не треба
)))
Але й інші можуть знадобитися/трапитися, просто набагато рідше)
Дякую за активність, це мене мотивує писати далі, дуже радий, що контент був корисним!
По хедерах в записці прикріпленій до голубів)
Які? Я завжди відкритий до конструктивної критики)