есть ли способ соствать кэш из всех датасорсов, которые прописаны в контейнере? 

тоесть выполнить статический метод, который бы вернул все созданые в контейнере jdbc-соединеия и их сохранить в HashMap, а после по имени брать из этого HashMap датасорсы

P.s. использую WebSphere 6.1

средствами JNDI API можно получить все объекты и подконтексты в нужном контексте.
соответственно, остается только понять их тип (datasource ли это) или искать в контексте, где априори лежат datasources (например, в локальном jndi-дереве по контексту java:comp/env/jdbc)

Все-таки считается более правильным получать ссылку на DS по имени из JNDI,
нежели  помещать ее в HashMap, хотя это будет  относительно и более медленно.
Это позволяет держать DAO объекты, которые ничего не знают о модели.

позвольте не согласиться.
кеширование фабрик (в т.ч. datasources) - очень полезная вещь, и многие design patterns явно предлагают использование кеширования ресурсов, затратных при получении.

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

спасибо за советы ... уже кое-что начало получаться, в понедельник будет новая рабочая неделя и новые силы   

To ekr

1. Я читал Вашу статью, и не согласен с предложенной Вами терминологией,
    тем более, что DataSource, похоже, только Вы называете фабрикой.
    Если бы мы не пересеклись бы с Вами в этом топике и по близкому вопросу,
    я не стал к этому обращаться. Дело в том, что "источники данных" (DataSources)
    сами порождаются (как правило) с помощью фабрик и, хотя по смыслу могут
    быть отнесены к фабрикам. являются больше описателями подключения и
    посредниками создающими оное, нежели фабриками, каковые по смыслу
    шаблона должны обеспечивать генерирование объектов РАЗНЫХ классов,
    но одного назначения. Тогда как DataSource генерирует множество
    объектов одного класса и, более того, с одинаковыми параметрами, в связи
    с чем (мне кажется) применение термина фабрика к этому объекту крайне
    нежелательно, так как здесь отсутствует прямое пересечение с одноименным
    шаблоном

2. Сохранение ссылки на DataSource в службе, обеспечивающей работу с объектом
    DAO, связанным с конкретным источником - разумеется, правильное решение.
    Однако с терминологической точки зрения я не стал бы называть это кэшированием.
    А вот сохранение всех источников данных в HashMap это действительно кэширование.
    И от него, на мой взгляд разумно отказаться, поскольку JNDI также обеспечивает
    кэширование, однако более универсальным способом - для того и сделано.
    Механизм гибкий, однородно работает во всех серверах и обеспечивает доступ
    из любого места приложения, а посему и более предпочтительный.

при поиске в локальном jndi-дереве


получаю ошибку:


в чем загвоздка?

немного упорства и найдуться ответы на все вопросы )

нашел решение:


и желаемый ответ:

Могу присоедениться к mbasil в вопросе кэширования.

Если рассматривать локальный вызов DataSource через JNDI, то скорость получения будет достаточно велика. В конце концов вызов идет в рамках одной JVM. И вряд ли это радикально скажется на быстродействии. Если проектирование сделано так, что частота получения DataSource сравнимы с общим временем работы - то такое проектирование надо переработать. Ибо плохо сделано.

Если же вызов происходит удаленно - то кэширование бессмысленно совсем.