Это безопасно с точки зрения управления операциями / изменениями, но не безопасно с точки зрения программиста.
С точки зрения программиста, конфигурация DataSource может быть изменена во время выполнения, и поэтому всегда следует повторять поиск.
Но это не так, как происходит в реальной жизни.
Когда необходимо осуществить изменение источника данных, это делается с помощью процедуры управления изменениями.Существует запись AC / R, и эта запись указывает, что приложение будет иметь время простоя.Другими словами, работники, выполняющие c / r, отключат приложение, внесут изменения и вернут его обратно.Никто не делает такие изменения на живой AS - по соображениям безопасности.В результате вы не должны принимать во внимание возможность того, что DS изменяется во время выполнения.
Так что любой постоянный синхронизированный общий кэш в этом случае хорош.
Получите ли вы повышение производительности?Это зависит от реализации AS.Вероятно, он имеет собственный кеш, но этот кеш может быть более общим и таким медленным, и на самом деле вы вообще не можете рассчитывать на его наличие.
Вам нужно построить кеш?Ответ обычно приходит из тестов производительности.Если проблем нет, зачем тратить время и рисковать?
Резюме: да, создайте простой кэш и используйте его - если это оправдано повышением производительности.
Особенности реализациизависит от ваших предпочтений.У меня обычно есть кеш, который выполняет поиск по требованию и имеет синхронизированную карту jndi-> объекта внутри.Для кеша с высокой степенью параллелизма я бы использовал блокировки чтения / записи вместо простой синхронизации - т.е. многие операции чтения могут идти параллельно, в то время как добавление новой записи получает эксклюзивный доступ.Но это детали, которые сильно зависят от деталей заявки.