Кэширование InitialContext и DataSource в веб-приложении Java EE - PullRequest
Новая
       53

Кэширование InitialContext и DataSource в веб-приложении Java EE

2 голосов
/ 19 февраля 2011

В следующей ссылке на Connector / J для JDBC / MySQL предлагается, чтобы мы кэшировали экземпляры InitialContext и Datasource. Будет ли просто сделать это частным статическим экземпляром для решения проблемы кэширования? Разве не нужно беспокоиться о безопасности потоков (если вообще)? Какое «лучшее» место для кэширования это для веб-приложения (Restlet + glassfish / Java EE + mysql) ??

Существует класс GenericDAO, который, так сказать, является root классов доступа к данным. Так что, если бы статические экземпляры действительно решили проблему? Это заставит некоторые методы быть статичными, чего мы не хотим. Предложения ??

Спасибо! 

public void doSomething() throws Exception {
/*
* Create a JNDI Initial context to be able to
* lookup the DataSource
**
In production-level code, this should be cached as
* an instance or static variable, as it can
* be quite expensive to create a JNDI context.
**
Note: This code only works when you are using servlets
* or EJBs in a Java EE application server. If you are
* using connection pooling in standalone Java code, you
* will have to create/configure datasources using whatever
* mechanisms your particular connection pooling library
* provides.
*/
InitialContext ctx = new InitialContext();
/*
* Lookup the DataSource, which will be backed by a pool
* that the application server provides. DataSource instances
* are also a good candidate for caching as an instance
* variable, as JNDI lookups can be expensive as well.
*/
DataSource ds =
(DataSource)ctx.lookup("java:comp/env/jdbc/MySQLDB");

/*
*Remaining code here...
*/
    }

Ответы [ 2 ]

4 голосов
/ 01 апреля 2011

Если вы используете JAX-RS, тогда вы можете использовать @Context аннотацию.

* 1006 Е.Г. * 

@Context
private ServletContext context;

@GET
@Path("whatevers")
public List<Whatever> getWhatevers() {
    DataSource dataSource = Config.getInstance(context).getDataSource();
    // ...
}

Однако, если аннотация @Resource также поддерживается в вашей среде Restlet, вы можете использовать ее как хорошо. 

@Resource(mappedName="jdbc/MySQLDB")
private DataSource dataSource

Технически, в свою очередь, лучше помещать в EJB, который вы, в свою очередь, вводите с помощью @EJB в своем веб-сервисе. 

@Stateless
public class WhateverDAO {

    @Resource(mappedName="jdbc/MySQLDB")
    private DataSource dataSource

    public List<Whatever> list() {
        // ...
    }

}

с 

@EJB
private WhateverDAO whateverDAO;

@GET
@Path("whatevers")
public List<Whatever> getWhatevers() {
    return whateverDAO.list();
}
2 голосов
/ 31 марта 2011

Следуя ссылке BalusC , я могу подтвердить, что мы могли бы сделать то же самое при использовании Restlet.Однако в соответствии с кодом в примере для получения экземпляра конфигурации, который вы передаете в ServletContext в качестве аргумента.Restlet похож на «другой» фреймворк, который использует сервлеты в качестве адаптера для самостоятельной настройки.Поэтому будет сложно передать ServletContext в качестве аргумента откуда-то еще в коде (Restlet использует свой собственный Context объект, который концептуально похож на ServletContext)

Для моего случая статическийметод, возвращающий кэшированный источник данных, кажется «достаточно чистым», но могут быть и другие подходы к проектированию / организации.

...