Как использовать jndi datasource в dao?

Question

Я пытаюсь сделать свой первый веб-проект, используя tomcat, jsp, сервлеты и log4j. У меня есть TO как: Пользователь, Тема, факультет и т.д., и DAO объекты, такие как: UserRepository, SubjectRepository, FacultyRepository и т.д. С репозиториев У меня есть следующие иерархии (не все объекты, помещенные): Инициализация DataSource в AbstractRepository идет этот путь :

public abstract class AbstractRepository<T> implements Repository<T> { 

private final static Logger LOG = Logger 
     .getLogger(AbstractRepository.class); 
private static final DataSource ds = init(); 

private static DataSource init() { 
    DataSource dataSource = null; 
    try { 
     Context initContext = new InitialContext(); 
     dataSource = (DataSource) initContext 
       .lookup("java:/comp/env/jdbc/mydb"); 
    } catch (NamingException ex) { 
     LOG.error("Cannot obtain a connection from the pool", ex); 
    } 
    return dataSource; 
} 
protected Connection getConnection() throws SQLException { 
    return ds.getConnection(); 
} 
.... 
} 

Так что теперь, если хранилище нужен Connection его просто вызывает родительский getConnection() метод.

Вопрос заключается в том, что лучше иметь один DataSource объект в AbstractRepository и каждый репозиторий подкласс получит Connection с использованием метода в родителю или каждый подкласс должен иметь свой собственный private final DataSource поле, которое будет инициализирован в конструкторе? Тогда объясните мне: если я выберу первый способ, я должен наложить метод getConnection synchronized ключевое слово? И если я выбираю второй способ: тогда репозитории подкласса должны быть одинарными, потому что каждый раз, когда запрос приходит к сервлету, он создает некоторый репозиторий, и поэтому он будет несколько DataSources? Или Tomcat знает через context.xml файл Сколько подключений он должен хранить? Я только что смутился. Не могли бы вы объяснить лучшие практики? Может быть, мне нужно что-то переделать?

Answer 1

Я сталкивался с этим много раз раньше. У меня был бы класс под названием CommonDao, похожий на ваш AbstractRepository. Connection или DataSource был переменной, принадлежащей CommonDao, но она не была статичной ... поэтому каждый экземпляр CommonDao имел свою собственную копию. Поэтому мой ответ заключается в том, что до тех пор, пока вы не создадите AbstractRepository.ds static, вы должны быть в порядке.

Проценты за это (с использованием DataSource являются частью AbstractRepositor, но не статическими) заключается в том, что у вас есть один общий способ получения вашего DataSource и может перезаписывать его, если нужно, подклассами (для этого потребовалось бы сделать ds protected) ,