Обновить
6
0

Пользователь

Отправить сообщение

И ещё один банальный пример технического ограничения: мне нужно прикрыть optimistic concurrency только одно поле в сущности. Или даже просто разделить поля с разным паттерном доступа (чтение/запись), чтобы это всё лучше чувствовало себя под нагрузкой.

Лично мне без разницы, как именно человек получил знания, которые позволили ему пройти техническое интервью. Если был готов ходить на курсы и хватило терпения их закончить значит мотивация всё же неплохая. Английский тоже можно самостоятельно изучать, только мало у кого получается.

Только никакие курсы не заменят реального опыта. Не бывает мидлов после курсов.

В целом идея с RabbitMQ мне нравится. Смущает только, что такую блокировку придётся дольше держать (взять задачу, подготовиться к запросу, послать его, сохраниться и подтвердить). Но, в зависимости от того, где что развёрнуто, наверное, может быть не хуже.
Ну, как мне кажется у любого подхода есть своя применимость. Вообще, обилие триггеров на таблицах может снизить производительность insert-ов. Код который Вы выполняете в триггере по умолчанию выполняется в той же транзакции что и insert. И в том же потоке. А здесь все сделает менеджер задач Oracle, в фоновом потоке. Еще, Вам видимо придется самостоятельно реализовать обработку сообщений, полученных из триггеров, а здесь предлагается уже готовое решение. Зато, вероятно, гибкость которую Вы получите в случае отказа от OCN будет больше. Вопрос только в том, нужна ли она.

Информация

В рейтинге
Не участвует
Зарегистрирован
Активность