Трохи не розумію, як наче термінуюча операція collect всередині Callable лямбди розуміє, що вона всередині ForkJoinPool виконується, але почитаю, розберусь.

Розібрався

The trick is based on ForkJoinTask.fork which specifies: “Arranges to asynchronously execute this task in the pool the current task is running in, if applicable, or using the ForkJoinPool.commonPool() if not inForkJoinPool()”

stackoverflow.com/a/22269778/5020294

І, так розумію, більш фічаста бібліотека, щоб робити це явно github.com/...​varit/parallel-collectors

що в паралельних стрімах неможливо вказати із яким ExecutorService працювати, то є простий підхід як вказати який сервіс використовувати:

Вельми вдячний, я про таке не знав, дякую за підказку.
Трохи не розумію, як наче термінуюча операція collect всередині Callable лямбди розуміє, що вона всередині ForkJoinPool виконується, але почитаю, розберусь.

Стосовно

автоматичний isNotXXX

Я залюбки допоможу оформити JEP,

Ну, яка може бути мотиваційна частина для синтаксичного цукору? :-)

Компілятору все одно, а людині, здається, легше читати lingam.isNotShort(), бо lingam.isShort() та !lingam.isShort() «виглядають» практично однаково.

(вибачте за вульгарність, це я так, для сміху)

del

Трохи офф-топік пішов.

Наскільки я пам’ятаю, стрім параллел всередині працює на Fork Join Framework, який має свій статичний пул тредів 1 на всю жвм.

Я теж таке пам’ятаю. Тому, здається, є рекомендація в parallel робити хіба що СPU операціі, тому що I/O може «вичерпати» той єдиний для всіх ForkJoinPool і це заафектить інші parallel стріми. Тут, звісно, треба зауважити, що паралельний I/O — це дивна ідея, і логічніше це робити однією bulk операцією. Коротше кажучи, я parallel взагалі не використовую, і необхідності нема, і не до кінця розумію, як з ним без явного ExecutorService коректно працювати.

Хотілося би думку Дениса Макогона, як причетного до розробки JDK, почути.

наявність Collection.isEmpty() і паталогічна відсутність .isNotEmpty()

З цим теж, звісно, згоден. Було б гарно зробити на рівні мови синтаксичний цукор для кожного isXXX() метода автоматичний isNotXXX, тому що в !longButSelfExplainableObjectName.isFineQualifiedBooleanMethod() знак оклику на початку, особливо біля «l», не видно. Тяжка спадщина assembler/C, 0 — це false, 1 — це true; добре, що хоч boolean завезли.

Обурення розумію, погоджуюсь, але дозвольте запитати. A JDK Stream::parallel не порушує цю концепцію? У нього ж теж, здається, ExecutorService назовні не стирчить?

Дякую за інформацію.

Трохи око сіпається від

double price

та

Product product = new Product();
product.setPrice(200);

... а так гарна оглядова стаття.

Капець, скільки слів замість коду!

по-перше — читабельність

Так, читабельність дасть. Для цього достатньо  boolean shouldBeDeleted = timer.expired() && !timer.recurrent() написати, але проблему це не вирішить.

тести на перевірку самого кондішена if(твоєї нової функції коли вона вертає тру а коли фолс)

Ну? І де ці тести? Як вони будуть виглядати? От я в цих закарлючках &&, ||, ! помилився і написав

boolean shouldBeDeleted() {
          return timer.expired() || timer.recurrent();  
}

і агрегований результат виконання буде не тим шо ти очікуєш.

Як цю приватну функцію тестувати? Вона не приватна? Ще цікавіше.

P.S. У книзі було щось на тему, що об’єкт у скоупі одного методу смикати більше одного разу — це «запах»?

а як вважаєш шо легче тестувати дві маленькі функції

У мене, як то кажуть, ООП композиція головного мозоку.
Я пишу (і закликаю писати) timer.shoudBeDeleted()

Якщо чужий final class, то

class MyTimer implements Timer {
    @Delegate
    private final Timer timer;

    boolean shouldBeDeleted() {
          return time.expired() && !timer.recurrent());  // може правильно, а може і ні. В тестах розберемось
    }
}

Тепер ти, будь ласка, розкажи, як тестувати

цикломатичну складність функції

shouldBeDeleted(timer)?

це особливості її роботи... Деякі з цих ПРОБЛЕМ РОЗРОБНИКА можна усунути обравши відповідний рівень ізоляції транзакцій, або застосувавши блокування.

Ну, в такому формулюванні згоден, звісно.

А то ви пишите

Насправді проблеми, згадані у розділі, — дещо вигадані проблеми.

... можна по різному зрозуміти.

От автор, повторюсь, ігнорує Lost Updates у своєму другому прикладі тому що, мабуть, не розуміє, що саме копі-пастить з ChatGPT.

А так-то у нас проблем немає, так. Просто знати різні особливості та код без багів писати, ось і все.

Давайте ще раз.

Проблема паралельного доступу...
Основні проблеми паралельного доступу:
Фантомне читання (Phantom Reads)
Неповторювані читання (Non-Repeatable Reads)
Втрати оновлень (Lost Updates)
Аномалії читання-запису (Read-Write Anomalies) — незрозуміло, що автор має на увазі, припустимо Read/Write Skew

Це як — в сучасних СКБД (в Oracle, наприклад) — вже не проблеми? Пофіксили? ))

Ці проблеми тільки

у ранніх версіях MS Sql

були?

інкапсулювати умовні конструкції: if(shouldBeDeleted(timer)) краще, ніж if(time.expired() && !timer.recurrent()));

А тестувати це як? Ну, напишу я натомість timer.expired() || timer.recurrent().
Як потім

якщо знайшли баг у функції — напишіть тест на це;

...?
Дивують ці переходи від наче ООП на процедурний стиль.

Але добре, що автор принаймі реагує на статтю, на відміну від колеги.

Привіт, Дмитро

Двукратна імплементація репозиторія боже яка діч.

Не до того прискіпуєшся, дозволь я поясню.

Не перший раз чую навколо і на ДОУ зокрема дві пов’язані думки:
1) домен має бути відв’язаний від персістанса. ДДД, гексональна архітектура, оце все. Власне ТС про це саме питає.
2) якщо персістанс робиться окремо, то чи потрібен там взагалі ОРМ (знову ж таки, що таке ОРМ? Який ОРМ? Hibernate та MyBatis — це, мяко кажучи, різні речі)

Стосовно першої — я в неї тупо практично не вірю. Не буває такого ідеального домену, складнішого за хелло-ворд, якому що в SQL, що в S3, що в графовій БД зберігатися — однаково. Ти гарно висловився, я можу тільки ППКС. Але от стаття на baeldung — як раз про це. Коментарі там, нажаль, закриті, а так я би спитав: а ну перейдіть з NoSQL на SQL, подивимось на перформанс eager-loading orderItems. Чому eager-loading? Ну, а який, домен-то відокремлений.

Якщо припустити, що репозиторій окремо від домена, можна починати спеціальну олімпіаду «Hibernate тармазіт і ваабще ні нужєн».

Ці думки, строго кажучи, різні, але я їх об’єдную в один підхід, тому що в мене (і в тебе, здається, теж) — так, домен прибитий до persistance, але я від цього не страждаю, а насолоджуюсь.

Тим не менш, щоб був не просто срач, а якийсь конструктив, я не полінувався написати приклад рекурсивного lazy-loading-у і всіх їм дістаю, щоб показали мені світло істини.

ТС, молодець, не посоромився, високовчені архітектори і прирівнені до них — до таких примітивних кодерських задач не опускаються.

Але наголошую — це не проблема.

Знову не зрозумів. Що — не проблема?

Можливо дещо пербільшив у попередньому повідомленні

Трохи є. По різному можна зрозуміти, що проблем нема, типу, і транзакції вже менеджити не треба, тому і перепитав.

Фантомне читання
— треба розуміти, що ви читаєте дані, якими вони були на початок виконання оператора або транзакції

Га? Тобто, що мається на увазі?

Втрати оновлень
— якщо якась з транзакцій не може бути виконана через конфлікт з іншою транзакцією, то вона завершиться помилкою. Просто треба після кожного звернення до бд перевіряти статус завершення операції.

А ящо нема конфлікту? Другий приклад з статті — це якраз про Lost Updates.

фантомне читання було у ранніх версіях MS Sql
— мається на увазі, що читалися вставлені\змінені дані ще не зафіксованих інших транзакцій.

Це не Phantom Read, а Dirty Read. Я з MS Sql не працював, але здається, так, він дозволяє виставляти Read Uncommitted.

Для Postgresql DDL виконується як частина транзакції нарівні з DML.

Хм, не знав, і навіть не спадало на гадку таке робити. Не те, щоб одразу практичне застосування придумав, але в будь-якому випадку дякую

В більшості сучасних провідних СКДБ таких проблем не існує.

Яких проблем не існує в сучасних провідних СКДБ? Не зрозумів з контексту, розгорніть, будь ласка

У коментарях майже все вже розібрали, али додам свої 5 копійок.

1. Вибачте, Назар, стаття не виглядає як «так болить, що не можу не писати, буду сперечатись з кожним зауваженням». Вангую, що автора ми в коментарях взагалі не побачимо. Невже роботодавець вимагає ще і написання курсових?

2. Ну, дякуючи ChatGPT, тепер це легко для автора, але тяжко для читачів, оці всі «основні теми, ключові принципи, значне застосування і практичний вплив» з першого абзацу. Це питання до редакції ДОУ (та й всього світу), що з чим робити.

3. Про «команду SAVEPOINT» це з власного досвіду? Чи copy-paste з ChatGPT? Схоже на риторичне питання.

4. Шановні колеги, треба щось робити з Read Skew. Я вже не перший раз чую думку (у статті це словами написано, а другим прикладом показано), що транзакції — це про модифікації, а декілька селектів перед транзакцією — це норм. Ось є коментар, або ось людина інтуітивно відчуває проблему, а її натомість цькують.

5. Про достатній баланс рахунку з першого приклада вже декілька разів згадали.

6. У статті згадуються Lost Updates, а другий приклад — це якраз їх наочна ілюстрація.
Якщо спочатку прочитати SubscriptionService.getExpiredSubscriptions(), потім у паралельній транзакції відбудеться якась активація, то перша транзакція все одно виставить expiredSubscription.update({ status: 'expired' }. Це і є lost update.

7. Трохи офтопік. Можна для незнайомих з нодою викликати, будь ласка, невелику пояснювальну бригаду?

        await Promise.all(
          expiredSubscriptions.map((expiredSubscription) =>
            expiredSubscription.update({ status: 'expired' }, { transaction }),
          ),
        );

Що тут відбувається — простими словами? У ноди по дефолту неблокуючі драйвери до БД? Навіть якщо так, транзакція ж одна? Як працює та який виграш дає Promise.all у цьому прикладі?

Мабуть, хтось знає про Read Skew

С какого из своих проектов?

Из любого, на ваш выбор.

Чем они — «ваши»?

Я не претендую на новаторство, только стараюсь правильно использовать инструменты.

стягивайте SQL код в один, или несколько модулей.
Оборачивайте его в процедуры.

Ок, есть модуль, есть процедура, в ней.

update employee set salary = salary * 1.1 where department_id = x;

Если не так, или не правильно понял, поправьте всё что угодно.

Как из этого sql кода получить тот аудит, о котором у нас вроде бы начал получаться разговор? Т.е. чтобы при вызове процедуры также летели insert-ы в табличку аудита «кто, что, когда, старое_значение, новое_значение»?

Как?
Зависит от существующего кода.

Приведите, пример, пожалуйста.
Какой именно из ста пицот примеров с гитхаба?

Свой. Не надо гитхаб. Я рассказываю свои решения, вы — свои.
Или вы про свой репозиторий на гитхабе? Тогда, наоборот, показывайте скорее.

и с sql update решаются. зависит от того как организовано размещение и использование SQL кода.

Типа: я sql update-ы организовываю и размещаю так. Поэтому если нужен такой странный аудит, сделаю то-то.