Проблема параллелизма с использованием spring, dbcp и postgres

Стек программного обеспечения, который я использую: tomcat-> spring-> hibernate-> DBCP -> postgreSQL

У меня есть запрос, который ищет некоторые данные, используя столбец типа «отметка времени без часового пояса».

Если приложение протестировано в однопользовательском режиме, то проблем нет.

Я использую JMeter для проведения стресс-теста и вижу, что иногда запрос не выполняется. Это может быть воспроизведено только в том случае, если несколько пользователей обращаются к приложению одновременно (более 20 в одну и ту же секунду).

Ошибка примерно такая:

org.postgresql.util.PSQLException: ОШИБКА: отметка времени вне диапазона: «20120100-09-26 00:00:00.000000 -04:00:00»

org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:2062) org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:1795) org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl. java:257) org.postgresql.jdbc2.AbstractJdbc2Statement.execute(AbstractJdbc2Statement.java:479) org.postgresql.jdbc2.AbstractJdbc2Statement.executeWithFlags(AbstractJdbc2Statement.java:367) org.postgresql.jdbc2.AbstractJexedbc2Statement. 271). java:208) org.hibernate.loader.Loader.getResultSet(Loader.java:1808) org.hibernate.loader.Loader.doQuery(Loader.java:697) org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java: 259) орг. hibernate.loader.Loader.doList(Loader.java:2228) org.hibernate.loader.Loader.listIgnoreQueryCache(Loader.java:2125) org.hibernate.loader.Loader.list(Loader.java:2120) org.hibernate. loader.hql.QueryLoader.list(QueryLoader.java:401) org.hibernate.hql.ast.QueryTranslatorImpl.list(QueryTranslatorImpl.java:361) org.hibernate.engine.query.HQLQueryPlan.performList(HQLQueryPlan.java:196) org.hibernate.impl.SessionImpl.list(SessionImpl.java:1148) org.hibernate.impl.QueryImpl.list(QueryImpl.java:102) org.hibernate.ejb.QueryImpl.getResultList(QueryImpl.java:67)

Версии, которые я использую:

  • кот 6.0.26
  • весна 3
  • ДБКП 1.4
  • postgresql-8.4-701.jdbc4.jar
  • Версия PostgreSQL: 8.4.4-0ubuntu10.04

postgresql spring concurrency apache-commons-dbcp
person Dani Cricco    schedule 07.09.2010    source источник

Ответы (2)


arrow_upward
2
arrow_downward

В вашем Java-коде у вас где-нибудь есть небезопасное использование объекта DateFormat? Странные и удивительные ошибки даты часто возникают из-за такого рода проблем?

private static final DateFormat fmt = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss.SSS");

становится

private static final ThreadLocal<DateFormat> fmt = new ThreadLocal<DateFormat>() {
    @Override
    protected DateFormat initialValue() {
        return new SimpleDateFormat("yyyy-MM-dd HH:mm:ss.SSS");
    }
}

См. Формат даты, ThreadLocal

person Jon Freedman    schedule 08.09.2010
comment
спс за ответ. Код выполняется внутри метода и использует только переменные, объявленные в методе. - person Dani Cricco; 08.09.2010
comment
Взгляните на p7spy — p6spy.com — вы можете настроить его как прокси-драйвер JDBC для регистрации всех операторы, работающие с базой данных, должны помочь вам точно определить запрос, вызывающий проблему, и, возможно, найти, откуда были вызваны операторы. - person Jon Freedman; 08.09.2010

arrow_upward
1
arrow_downward

метка времени вне диапазона: "20120100-09-26 00:00:00.000000 -04:00:00"

Вы работаете в 20120100 году? (двадцать миллионов) Вы уверены? Максимальный год для метки времени — 294276, но я уверен, что ваш ввод неверен.

Это также не имеет ничего общего с параллелизмом, просто вне диапазона ввода.

person Frank Heikens    schedule 08.09.2010
comment
это странно. У меня есть тест jmeter, который запрашивает некоторые данные с использованием метки времени. Если количество пользователей меньше 20, то проблем нет. Я начинаю увеличивать количество пользователей, и проблема появляется время от времени. - person Dani Cricco; 08.09.2010
comment
Тогда проблема может быть в JMeter: он использует неверные данные, у базы данных нет другого выбора, кроме как отклонить запрос и выдать ошибку. - person Frank Heikens; 08.09.2010