2010-09-07 13 views
0

La pile logicielle J'utilise est: tomcat-> printemps-> hibernate-> DBCP -> postgreSQLproblème Concurrency utilisant un ressort, DBCP et postgres

J'ai une requête qui recherche de certaines données en utilisant une colonne de tapez "horodatage sans fuseau horaire".

Si l'application est testée en mode mono-utilisateur, il n'y a pas de problème. J'utilise JMeter pour faire un test de stress et peut voir que parfois la requête a échoué. Cela ne peut être reproduit que si plusieurs utilisateurs accèdent à l'application en même temps (plus de 20 dans la même seconde).

L'erreur est quelque chose comme:

org.postgresql.util.PSQLException: ERREUR: timestamp hors de portée: "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.AbstractJ dbc2Statement.executeWithFlags (AbstractJdbc2Statement.java:367) org.postgresql.jdbc2.AbstractJdbc2Statement.executeQuery (AbstractJdbc2Statement.java:271) org.apache.commons.dbcp.DelegatingPreparedStatement.executeQuery (DelegatingPreparedStatement.java:96) org.apache .commons.dbcp.DelegatingPreparedStatement.executeQuery (DelegatingPreparedStatement.java:96) org.hibernate.jdbc.AbstractBatcher.getResultSet (AbstractBatcher.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) org.hibernate.loader.Loader.doList (Loader.java:2228) org.hibernate.loader.Loader.lis tIgnoreQueryCache (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)

Les versions que j'utilise sont:

  • tomcat 6.0.26
  • ressort 3
  • DBCP 1,4
  • postgresql-8.4-701.jdbc4.jar
  • Version PostgreSQL: 8.4.4-0ubuntu10.04

Répondre

1

timestamp out of range: "20120100-09-26 00:00:00.000000 -04:00:00"

Vous travaillez en 20120100? (vingt millions) Es-tu sûr? L'année maximale pour un horodatage est 294276, mais je suis certain que votre entrée n'est pas correcte.

Cela n'a rien à voir avec la concurrence soit, juste à l'entrée de gamme.

+0

qui est la chose bizarre. J'ai un test jmeter qui interroge certaines données en utilisant l'horodatage. Si le nombre d'utilisateurs est inférieur à 20, il n'y a pas de problème. Je commence à augmenter le nombre d'utilisateurs et le problème apparaît de temps en temps. –

+0

Ensuite, le problème pourrait être JMeter: il utilise des données non valides, la base de données n'a pas d'autre choix que de rejeter la requête et une erreur. –

2

Dans votre code java avez-vous l'utilisation non threadsafe d'un objet DateFormat partout? Les erreurs de date étranges et merveilleuses proviennent souvent de ce genre de problème?

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

devient

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

Voir DateFormat, ThreadLocal

+0

tks pour la réponse. Le code s'exécute à l'intérieur d'une méthode et n'utilise que des variables déclarées dans la méthode. –

+0

Jetez un oeil à p7spy - http://www.p6spy.com/ - vous pouvez le configurer comme un pilote JDBC proxy pour vous connecter toutes les déclarations en cours d'exécution contre le db - devrait vous aider à identifier la requête qui est à l'origine du problème et potentiellement trouver où les déclarations ont appelé. –