Передача источника данных jdbc против передачи объекта Connection - от сервлета к классу java

У меня есть основной сервлет, который обрабатывает запросы post/get.
Я использую пул соединений (jdbc/mysql с Glassfish v3), и мой код сервлета:

public class Controller extends HttpServlet {
private DataSource datasource;
@Override
public void init() throws ServletException {
      super.init();
     try {
        //Database Connection pooling:
        InitialContext ctx = new InitialContext();
        datasource = (DataSource)ctx.lookup("jdbc/MySQLPool");
      }
      catch (Exception e) {
         e.printStackTrace();
       }
   }
private Connection getConnection() throws SQLException {
    return datasource.getConnection();
    }
protected void processRequest(HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException {
    Connection connection=null;
    try {
            connection = datasource.getConnection();
            Object obj=  cmdFactory.getInstance().getCommand(Cmd).execute(connection);
        }

etc... и в конце сервлета в блоке finally я закрываю соединение

Итак, прямо сейчас я передаю объект «соединение» в качестве параметра в последней строке, который будет использоваться другими (не сервлетами) классами Java через нижние уровни приложения. Это неправильно? лучше передать объект источника данных (а затем в конкретных классах сделать datasource.getConnection())? или есть что-то похожее на "getServletContext().getAttr(database)", которое можно использовать в других классах Java для получения этого соединения?


mysql jdbc connection-pooling servlets jakarta-ee
person ccot    schedule 21.01.2012    source источник

Ответы (1)


arrow_upward
3
arrow_downward

Источник данных позволяет получить соединение JDBC (в большинстве случаев из пула соединений). В среде сервлетов, если вы дважды запрашиваете соединение с DataSource, вы получите два разных соединения.

Таким образом, передача DataSource не имеет смысла: вы хотите, чтобы все объекты в цепочке вызовов использовали одно и то же соединение и фиксировались в конце.

И соединение должно быть закрыто методом, который получил его из DataSource, в блоке finally, иначе пул будет пропускать соединения, и у вас быстро закончатся доступные соединения.

person JB Nizet    schedule 21.01.2012
comment
очень признателен :) и да, что касается утечки, вы абсолютно правы, спасибо, что напомнили мне, потому что я забыл об этом! - person ccot; 22.01.2012
comment
Вопрос: как вы приблизительно оцениваете или рассчитываете, каким должен быть размер пула соединений для конкретного веб-приложения? Есть ли ссылка для подражания? это первый раз, когда я использую пул соединений, и я просто использовал параметры по умолчанию для стеклянной рыбы - person ccot; 22.01.2012
comment
I зависит от количества одновременных пользователей, количества подключений, которые фактически поддерживает база данных, количества потоков в пуле потоков. Вы должны провести нагрузочное тестирование своего приложения с ожидаемым количеством одновременных пользователей и посмотреть, какое число будет лучшим. И тогда вы должны проверить, соответствует ли реальность вашим ожиданиям. - person JB Nizet; 22.01.2012