Discussion :

[mysianne]

Bonsoir l'équipe !
Je suis depuis quelque temps confronté à un problème qui tente de m'arracher les cheveux de la tête.
J'ai une application JEE (Hibernate + EJB+ Glassfish+Postgres...) qui tourne depuis sur un serveur dans un réseau local sans problème. Mais depuis quelque temps j'ai une erreur qui se produit sans que je ne puis déterminer la cause. L'un des gros soucis est que l'erreur n'est pas automatique lors de l'exécution d'une partie du code. Non! elle surgit de manière imprévisible! et j'ai dans les log ceci:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
Caused by: org.postgresql.util.PSQLException: Une erreur d'entrée/sortie a eu lieu lors d'envoi vers le serveur.
	at org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:218)
	at org.postgresql.jdbc2.AbstractJdbc2Statement.execute(AbstractJdbc2Statement.java:451)
	at org.postgresql.jdbc2.AbstractJdbc2Statement.executeWithFlags(AbstractJdbc2Statement.java:350)
	at org.postgresql.jdbc2.AbstractJdbc2Statement.executeQuery(AbstractJdbc2Statement.java:254)
	at com.sun.gjc.spi.jdbc40.PreparedStatementWrapper40.executeQuery(PreparedStatementWrapper40.java:642)
	at org.hibernate.jdbc.AbstractBatcher.getResultSet(AbstractBatcher.java:186)
	at org.hibernate.loader.Loader.getResultSet(Loader.java:1787)
	at org.hibernate.loader.Loader.doQuery(Loader.java:674)
	at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:236)
	at org.hibernate.loader.Loader.loadEntity(Loader.java:1860)
	... 88 more
Caused by: java.net.SocketException: Connection reset by peer: socket write error
	at java.net.SocketOutputStream.socketWrite0(Native Method)
	at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:109)
	at java.net.SocketOutputStream.write(SocketOutputStream.java:153)
	at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82)
	at java.io.BufferedOutputStream.write(BufferedOutputStream.java:126)
	at java.io.FilterOutputStream.write(FilterOutputStream.java:97)
	at org.postgresql.core.PGStream.Send(PGStream.java:216)
	at org.postgresql.core.v3.QueryExecutorImpl.sendParse(QueryExecutorImpl.java:767)
	at org.postgresql.core.v3.QueryExecutorImpl.sendOneQuery(QueryExecutorImpl.java:1037)
	at org.postgresql.core.v3.QueryExecutorImpl.sendQuery(QueryExecutorImpl.java:644)
	at org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:190)
	... 97 more

Mes questions sont de savoir
- ce qui pourrait en être la cause
-si quelqu'un à déjà résolu un problème semblable
j'attends patiemment vos réactions et merci d'avance

[olivier.pitton]

Plop,

Es-tu sur que le serveur PG tourne durant cette erreur ? A quel moment fermes-tu les objets java.sql (Connection, ...) car tu peux potentiellement les fermer dans un thread, et tenter une écriture dans un autre.

Peux tu nous montrer un peu de code, de préférence où tu effectues ta requête qui plante, et le code à "proximité".

[mysianne]

Merci pour ta réponse olivier.

Es-tu sur que le serveur PG tourne durant cette erreur ?

La première fois que j'ai eu ce problème, j'ai juste redemarrer mon serveur PG et tout est rentré dans l'odre. ensuite, ce simple redémarrge n'a plus suffit. il fallait en plus que je redemarre aussi glassfish

j'utilise un pool de connection sur glassfish que j'injecte dans mon application via l'EtityManager (JPA). ensuite, je transforme cette entityManager en session hibernate grace à la methode

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

entityManager.getDelegate().getSession()

donc en bref c'est mon serveur qui gère mes connections (initiation et interruption).
Toutefois, dans une partie de mon code, j'ai besoin d'appeler une procedure stockée; vue qu'il n'est pas toujours possible de le faire avec hibernate, je suis obligé de récupérer l'objet Connection encapsuler dans ma session pour ce faire
bien entendu j'ai pensé qu'il n'est pas nécessaire de fermer cette connection vue que le serveur le fera probablement à mon insu. voici la partie du code:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
public double callPS(String art, String depot, Date dat, Connection con){
        try {
            CallableStatement proc = con.prepareCall("{ ? = call public.calcul_stocks(?, ?, ?) }");           
            proc.registerOutParameter(1, Types.DOUBLE);
            proc.setString(2, arg1);
            proc.setString(3, arg2);
            proc.setTimestamp(4, d);
            proc.execute();
            re =proc.getDouble(1);            
            proc.close();
        } catch (SQLException ex) {
            Logger.getLogger(AbstractGenericDao.class.getName()).log(Level.SEVERE, null, ex);
        }        
        return re;
 }

Je tiens aussi à rappeler que ce n'est pas une erreur que je peut reproduire à volonté. et c'est ce qu'il y a de vraiment embétant là car j'ignore encore ce qui en est la cause est-ce ce bout de code?

[mysianne]

Autre chose que j'ai oublié de préciser.
Travaillant avec des EJB Stateless, le serveur détruit les ressources JDBC apès chaque requete cliente. De ce fait, il m'étais impossible de récupérer ma connection via la session hibernate (puisque détruite par le serveur après une requete). j'ai, pour contourner cela, j'ai ajouté un EJB Statefull qui utilise un entityManager dont j'ai étendu le contexte de persistence. et c'est grace à cet EJB que je peut récuperer un Objet Connection.
est-il possible que les deux EJB utilise à un moment le même objet Connection provenant du pool et que pendant que la connection est fermé par le serveur (à cause du comportement Stateless Session Bean), la même connection ayant déjà une référence dans la session contenu dans le Statefull Session Bean tente d'être utilisé pour écrire des données?
Si cette théorie est juste, comment puis-je m'affranchir d'un tel comportement svp.

[olivier.pitton]

Plop,

N'utilise plus l'objet Connection mais passe par Hibernate pour effectuer ton appel à la procédure stockée. Pour cela, il te suffit d'appeler "createSQLQuery" depuis l'objet Session.

Quelque chose comme çà :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
 
Query query = session.createSQLQuery(
	"CALL GetStocks(:stockCode)")
	.addEntity(Stock.class)
	.setParameter("stockCode", "7277");
 
List result = query.list();
for(int i=0; i<result.size(); i++){
	Stock stock = (Stock)result.get(i);
	System.out.println(stock.getStockCode());
}

Je pense que tu utilises trop de technologies. Même si ce n'est pas le fond du problème, utilisé Hibernate + JDBC + à moitié JPA, n'est pas ce qu'il y a de mieux. Essaye de n'utiliser qu'une seule technologie, en l'occurence Hibernate.

Tu peux créer un EJB Singleton pour récupérer un DataSource depuis le serveur, si tu veux que les informations soient dans le serveur, et initialiser ta Session Hibernate.

L'EJB statefull est bizarre ici. Ca devrait être un Stateless.

[mysianne]

Merci encore Olivier,
ta requette fonctionne à condition de remplacer "CALL" par "select" comme en sql natif. Je résouds ainsi une partie du problème. Mais demeure que j'ai toujours besoin de Connection au moins pour récupérer mes Etats Jasper.
Pour celà j'ai opté pour un pool de connection différent de celui utilsé par mon EJB Stateless.

L'EJB statefull est bizarre ici. Ca devrait être un Stateless.

Le problème du Stateless est que à chaque requete, les ressources injectés dans l'EJB sont détruites (les Connections aussi) donc il est difficile de garder un tel objet. le seul moyen est soit de créer une connection JDBC directe ou de passer par un Statefull Session Bean.

En créeant un pool différent pour le Statefull, j'espère qu'on n'aura jamais un objets Connection partagé par le deux. ça l'air de marcher depuis ce matin puisque je n'ai plus eu cette erreur. j'attends encore pour voir si le problème est définitivement résolu. seul le temps me le dira. Merci pour ton aide une fois de plus

[mysianne]

je revient sur cette discussion pour apporter quelques correctif utiles.
Se servir en effet d'un EJB stateful juste pour récupérer l'objet connection assossié est grotesque; le faisant, on s'éloigne énormément des objectifs visé par la technologie: qui est vise à implementer une conversation étendu entre un client spécifique et le serveur. la solution que j'ai adopté et qui je pense est la meilleur est de récupérer la datasource du serveur

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
@Resource(name="maResource")
DataSource  ds;

et de récupérer un objet connection dans le pool