Здравствуйте, есть смысл разделить содержимое приложения по нескольким схамам.
Вычитал, что если в runtime менять базы данных, то выйдет дорого по перформенсу.

Собственно в SpringBoot можно сконфигурировать несколько dataSurces.
https://docs.spring.io/spring-boot/docs/current/reference/htmlsingle/#howto-two-datasources

Сконфигурировал. Всё работает. Собственно, хотел поинтересоваться, нет ли в этом случае какой-то загвоздки? Не повлияет ли как-то и каким-то образом на перформенс если при старте приложение будет поднимать коннекты к например 5 различным dataSources?
Буду благодарен за мнения..

Basil A. SidorovЕсли вас не беспокоит производительность несколько подключений к одной схеме, то не должна беспокоить и производительность нескольких подключений к разным схемам. - Немного не понял, - это вы ответили так, или просто сарказм?

Petro123_webdev_переведи это слово и скажи почему оно тебя беспокоит
))) performance - в данном случае скорость обработки запроса.

Весь "цыр-бор" в том, что я где-то на stackoverflow прочитал, что менять dataSource в runtime щыень затратная задача. Поэтому у меня и возник вопрос такой.
Конечно же, что dataSource создаются при старте, но хотел переспросить.

Но исходя из ваших ответов, понимаю, что всё ок, и не надо придумывать того чего нет.

Leonid Kudryavtsev_webdev_Здравствуйте, есть смысл разделить содержимое приложения по нескольким схамам.
I)
С database pool есть проблема, что кэшь PreparedStatement'ов внутри connection становится общий для всех модулей приложения. Отсюда недостатки:
1. Т.к. один коннекшен радостно передается между модулями, он собирает "мусор" из всех модулей
Соответственно:
2. Смысл кэша пропадает. Т.к. он маленький и нужные запросы из него банально в соседнем модуле вымываются
3. Кэш всегда "забит" под завязку, т.ч. происходит существенный перерасход памяти.

в этом смысле, разделения приложения по нескольким схемам в БД и нескольким подключениям connection pool, может дать определенные выгоды в смысле использования памяти JDBC драйвером.

Разумеется, зависит от грамотности данного "разделения" + специфики конкретных драйверов

Разбирался с безумным потреблением памяти Oracle JDBC драйверов в корпоративной системе.

II)
Разумное разделение всегда полезно в смысле простоты и удобства администрирования. Будет проблема, например ресурс леак (утечка сессий, незакрытые курсоры) -> проще найти место возникновения, проще устранить, меньше потери функциональности и проблемы из-за ошибки (есть надежда, что соседние модули не затронет) - пасибо за объяснение,
Может я просто ещё не работал с высоко нагруженными системами, или не понимаю чего, но. Такого как незакрытые курсоры и так д... Для этого сейчас есть SpringDataJpa, чтоб не парсить ResultSet-ы и так д..

Leonid KudryavtsevА зачем кому-то может понадобится менять dataSource в runtime ? - Я просто сказал, что прочитал на stackoverflow - к сожалению, не могу найти ссылку на пост, где о этом было написано.


Leonid KudryavtsevМне кажется, это примерно тоже самое, что говорить "перезагрузка app сервера в runtime очень затратная задача, поэтому app сервером лучше не пользоваться". Так-то оно так, кто спорит, но зачем сервер нужно перегружать в runtime, есть большая загадка ))). - ответил выше.

Petro123У тебя смесь три в одном:
- затратное
- во время выполнения
- скорость запроса.
Пиши код и проверяй на практике. - да, для особого тестирования пока времени, как всегда, не хватает, поэтому, если мысль залезла в голову, то лучше спросить глупость, но спросить..

maytonС датасорсами не будет проблем. Их можно подключить к приложению столько штук сколько надо. Но я бы озабочетился свободной памятью для Hiber контекстов и Ehcache если вы таковые используете. - Вот на счёт "Hiber контекстов" - спасибо. Ehcache - да, есть, но пока я не очень активно его внедряю, пока не вижу надобности. Так как данные динамичны и приходят с различных источников, строить для этого кэш - думаю в моём случае будет затратно очень, плюс отличное место для ошибок..

Герой дняу Спринга есть возможность на лету переключать датасорсы, точнее их конфигурации, через Spring Bus - насколько я погуглил - речь идёт о spring-cloud, где есть несколько микросервисов и так д, у меня пока один проект.