Сергей Соловьев

В приложении, которое использует Dependency Injection можно выделить 2 "области":
- Composition Root
- Остальное приложение

Composition Root - это место в котором собираются все зависимости воедино. О всех реализациях зависимостей должен знать только он.
Остальное приложение - это (тафтология) все остальное приложение. Они используют только интерфейсы и другие абстрации.

Обычно Composition Root - это входная точка приложения. В нем создается эта самая ServiceFactoryImpl (стандартные реализации, из конфигурации могут быть прочитаны флаги, создан в зависимости от платформы и т.д.), а затем как интерфейс IServiceFactory, передается в остальные места.

Т.е. в коде это будет как-то так

#include <IServiceFactory.h>

class Sample {
private:
    IServiceFactory _factory;
public:
    Sample(IServiceFactory factory): _factory(factory) { }
    DoSomething() { 
        auto service = _factory.CreateService();
        service.MakeStuff();
    }
}

int main() {
    auto factory = ServiceFactoryImpl(); // Читаем конфигурацию, параметры ОС и др.
    auto sample = Sample(factory);
    sample.DoSomething();
}

тебе просто нужно удалить контейнер, которому примаунчен этот вольюм.
пока контейнер ОСТАНОВЛЕН все ресурсы за ним еще сохраняются

Когда запускаешь команду сборки, просто пропускай этап тестов - gradle build -x test

1) Что будет с запросом UPDATE, если исполнение кода ещё не дошло до этого запроса, оно получается будет ещё доступна для запросов из другого кода?

Не понял, что имеется ввиду. Но если это про то - "будут ли видны изменения, которые сделаны до вызова этого UPDATE в транзакции", то это зависит от уровня изоляции других транзакций.
В случае SERIALIZABLE - нет, не увидят.

2) А если функцию sameFunc запустят много юзеров? Получается КАЖДЫЙ юзер будет ждать завершения предыдущих транзакций от всех остальных юзеров?

Так как указана SERIALIZABLE, то да:
- Если конфликтов не будет, т.е. никто не обновлял те же самые записи, то будут ждать
- Если кто-то одновременно обновил одни и те же данные, то будет конфликт транзакции

Стоит еще учесть, что если одна и та же запись обновлена одновременно разными транзакциями, то поздняя транзакция просто заблокируется и будет ждать: либо когда первая закоммит - тогда конфликт транзакции, либо первая выполнит откат и ты продолжишь выполнение
P.S. еще есть таймаут ожидания транзакции

3) А если все запросы в транзакции взаимодействуют только с полями конкретного юзера, то как это нужно реализовать в транзакциях? Вроде как объект транзакции один — сам node.js, который единожды подключается к БД.

А вот тут надо разобраться. Зависит от того как ты работаешь с БД.
Судя по названию ты используешь пул соединений (переменная pool) и каждый раз выполняешь запрос на нем. Я не знаю node.js и фреймворк для БД, который ты используешь, но что-то подсказывает, что на каждый такой .query создается отдельное подключение и выполняется запрос.
Если да, то этот код работать не будет, т.к. ты постоянно открываешь новое соединение, начинаешь транзакцию или запрос и закрываешь соединение. В этом случае, все начавшиеся транзакции завершатся сразу, а запросы, которые должны работать в транзакции будут выполняться сразу.
Чтобы все работало корректно - на каждом вызове этого метода открывай новое соединение и работай с ним. Тогда гонки в коде не будет. (Можно еще использовать пул соединений).

Дополнительно я бы еще реализовал логику повторных попыток выполнения, если был обнаружен конфликт транзакций (проверяй исключение)

1. Для тестирования выделения памяти нужно использовать dotMemory. У него есть отдельный плагин для всяких unit фреймвоков - https://blog.jetbrains.com/dotnet/2018/10/04/unit-...
Единственная проблема - она платная, а других аналогов мне не известно.
2. Нашел репозиторий с кодом для профилирования Unity, но последнее обновление 5 лет назад - https://github.com/donaldwuid/unitymemoryprofilert...
3. У самого Unity есть документация по профилированию памяти, но это не для юнит тестов, а для всего приложения - https://unity.com/how-to/analyze-memory-usage-memo...

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

Короткий ответ - да.
Длинный -
NoSQL - это обощенное название для всех НЕРЕЛЯЦИОННЫХ БД - ключ-значение (Redis), документо-ориентированные (MongoDB), графовые (Neo4J), семейство столбцов (Cassandra).
Каждая имеет свой язык запросов. Какие-то похожи на SQL (Cassandra имеет схожий синтаксис), какие-то можно превраить в SQL (у Mongo очень похож на SQL, можно сконвертировать простые запросы, как представленный например), другие вообще не похожи (Redis - это просто 1 строка команды в plain text).
Все что нужно - найти способ как транслировать этот SQL запрос в язык для целевой NoSQL.