Discussion :

[thc]

Bonjour,

je suis en train de bosser sur un servlet (déployé dans WebSphere).

Le servlet se connecte à une base de données Oracle en utilisant un pool de connection géré dans WebSphere.

Le pool fonctionne bien, le servlet presque bien

En fait, mon servlet sert de "driver" de base de données pour une autre application.

L'application envoie une requete POST au servlet pour chaque ordre base de données.

Le servlet l'execute, et renvoie le résultat à l'application cliente.



Cela fonctionne tres bien pour les requetes de type SELECT, mais pas pour les requetes de type INSERT/UPDATE/DELETE.

En effet, quand le client veut modifier des données, il envoie une requete (POST) pour faire faire un INSERT dans la base (par exemple), mais je ne veux pas commiter tout de suite (j'ai d'autres ordres à passer avant).

La demande de COMMIT va passer plus tard, dans une autre requete POST.

Hors j'ai l'impression, même si j'ai la même connection du pool tout au long de mon scénario (je ne le libere pas), que quelque chose a été quand même libéré car le commit ne commite rien en fait, et même les SELECT suivants ne voient pas les données


Si quelqu'un a quelques lumieres sur ce sujet, je suis preneur

merci d'avance.

a++
chris

[chouchou93]

bonjour

tu as une trace d erreur ou pas??

est tu sur lors de ton commit que c est bien la meme connection qui a fais les modifications? parce ca me semble bizard ton probleme.

J ai fais une chose similaire a ca que tu dis, c est a dire 2 requete, un select puis ensuite un update, j ai configuré pour que ce ne soit pas en autocommit et c est seulment le update qui commit le tout

[thc]

hello,

Je n'ai pas d'erreurs, c'est juste que mes tables ne sont pas modifiées.


Pour etre un peu plus clair, voilà mon scénario:

j'ai une classe "DriverSession" qui initialise le pool de connection

Code :

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

1
2
3
4
5
6
7
8
9
10
 
...
    private Connection conn ;
    private Statement statement ;
    private javax.naming.Context root;
    private javax.sql.DataSource datasource ;
...
    this.root = new javax.naming.InitialContext();
    this.datasource = (javax.sql.DataSource) this.root.lookup("jdbc/chris");
    this.conn = this.datasource.getConnection ( this.username , this.password ) ;

ensuite, j'ai 4 ordres POST suivants (pour simplifier) :
- un ordre qui me connecte à la BDD
- un ordre pour faire un SELECT
- un ordre pour faire un INSERT
- un ordre pour COMMITer

une fois connecté, je fais :
- select (100 objets retournés)
- insert dans la table (1 objet créé)
- commit
- select (toujours 10 objets retournés)


La connection se fait bien:

Code :

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

1
2
3
4
5
6
 
...
this.conn = this.datasource.getConnection ( user , pass ) ; 
...
conn.setAutoCommit(false);
...

Dans chaque appel sur chaque ordre, j'ai fait afficher les objets connection, statement et datasource, et j'ai l'impression que les objets sont les mêmes.

Sauf que d'un appel à l'autre, cela se comporte comme si le connection etait relachée, et donc pas commitée


voilà les traces que j'ai faites

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
26
27
28
 
// SELECT NAME FROM XXX_USERS ;
[6/23/06 15:34:02:466 CEST] 00000035 SystemErr     R  ** root       = javax.naming.InitialContext@3e443e44
[6/23/06 15:34:02:466 CEST] 00000035 SystemErr     R  ** datasource = com.ibm.ws.rsadapter.jdbc.WSJdbcDataSource@6413523e
[6/23/06 15:34:02:466 CEST] 00000035 SystemErr     R  ** conn       = com.ibm.ws.rsadapter.jdbc.WSJdbcConnection@351c351c
[6/23/06 15:34:02:469 CEST] 00000035 SystemErr     R  ** statement  = com.ibm.ws.rsadapter.jdbc.WSJdbcStatement@19be19be
 
// INSERT INTO XXX_USER (NAME) VALUES ('TESTTEST')
[6/23/06 15:34:37:561 CEST] 00000034 SystemErr     R  ** root       = javax.naming.InitialContext@3e443e44
[6/23/06 15:34:37:561 CEST] 00000034 SystemErr     R  ** datasource = com.ibm.ws.rsadapter.jdbc.WSJdbcDataSource@6413523e
[6/23/06 15:34:37:561 CEST] 00000034 SystemErr     R  ** conn       = com.ibm.ws.rsadapter.jdbc.WSJdbcConnection@351c351c
[6/23/06 15:34:37:561 CEST] 00000034 SystemErr     R  ** statement  = com.ibm.ws.rsadapter.jdbc.WSJdbcStatement@496c496c
[6/23/06 15:34:37:562 CEST] 00000034 SystemErr     R Query = [INSERT INTO XXX_USER (NAME) VALUES ('TESTTEST')]
[6/23/06 15:34:38:142 CEST] 00000034 SystemErr     R **>executeUpdate returned: 1
 
 
// COMMIT
[6/23/06 15:35:14:762 CEST] 00000034 SystemErr     R  ** root       = javax.naming.InitialContext@3e443e44
[6/23/06 15:35:14:762 CEST] 00000034 SystemErr     R  ** datasource = com.ibm.ws.rsadapter.jdbc.WSJdbcDataSource@6413523e
[6/23/06 15:35:14:762 CEST] 00000034 SystemErr     R  ** conn       = com.ibm.ws.rsadapter.jdbc.WSJdbcConnection@351c351c
[6/23/06 15:35:14:762 CEST] 00000034 SystemErr     R  ** statement  = com.ibm.ws.rsadapter.jdbc.WSJdbcStatement@2c242c24
 
 
// // SELECT NAME FROM XXX_USERS ;
[6/23/06 15:35:40:788 CEST] 00000034 SystemErr     R  ** root       = javax.naming.InitialContext@3e443e44
[6/23/06 15:35:40:788 CEST] 00000034 SystemErr     R  ** datasource = com.ibm.ws.rsadapter.jdbc.WSJdbcDataSource@6413523e
[6/23/06 15:35:40:789 CEST] 00000034 SystemErr     R  ** conn       = com.ibm.ws.rsadapter.jdbc.WSJdbcConnection@351c351c
[6/23/06 15:35:40:789 CEST] 00000034 SystemErr     R  ** statement  = com.ibm.ws.rsadapter.jdbc.WSJdbcStatement@4e164e16

[chouchou93]

tu as essayé de faire le update et select via un outil ?? en dehors de ton code??

[thc]

oui oui ça fonctionne bien.

Ce matin, j'ai aussi essayé de faire le commit directement apres le update, c'est à dire dans mon ordre POST "insert", et plus dans l'ordre POST "commit".

Là la table a bien été modifiée.

Je pense vraiement qu'il se passe quelque chose sur mes connections entre deux appels

a++
chris

[chouchou93]

tout dépend commetn tu as fais ta classe commit, comment l appel tu ? et ou? j ai l impression que ce ne st pas la meme connection que tu passes, je peux pas plus t aider car je n ai pas tout ton code, mais a ta place, je mettrai dans le finally de ta classe update le commit, enfin si cela rentre dns tes besoins

[thc]

Alors voilà comment est fait mon servlet:

la classe principale s'appelle "XXXDriver".

C'est lui qui répond aux POST (normal quoi).

Mon XXXDriver a un objet de classe XXXDriverSessionPool (je veux utiliser mon driver depuis plusieurs applications clientes).

Mon XXXDriverSessionPool contient en fait un Vector de XXXDriverSession;

Enfin, mes XXXDriverSession, ceux sont eux qui se connectent à la base.


Donc quand une requete POST (ou GET, en passant) arrive sur mon servlet XXXDriver, je retrouve une XXXDriverSession (initialisée aupravant par une autre requete POST ou GET) par un identifiant que je gere moi même.

une fois que j'ai récupéré mon XXXDriverSession, c'est ce dernier qui execute mon ordre SQL.

Dans ce "schéma" (si on peut appeler ça comme ça ), la "connection", la "datasource", etc... sont des attributs de l'objet XXXDriverSession

(si j'ai deux clients qui utilisent mon driver, je vais avoir deux sessions de drivers, avec chacun sa connection JDBC récupérée du pool).

Les ordres SQL sont passés depuis la classe principale XXXDriver:

Dans XXXDriver:

Code :

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

1
2
3
4
5
6
 
...
OPX2DriverSession session = 
  OPX2Driver.sessionsPool.getSession (sessionID);
session.orderCommit();
...

Dans XXXDriverSession:

Code :

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

1
2
3
4
5
6
7
8
9
 
...
public void orderCommit ( ) 
{
  // conn est un attribut de la classe XXXDriverSession, 
  // qui contient l'objet connection que je n'ai jamais libéré :/
  conn.commit();
}
...

ouf!!

merci de ta patience en tout cas

a++
chris

[chouchou93]

oui ca m avance pas trop, je ne sais pas si cela a un lien, mais fais tu un close apres le commit??

Code :

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

1
2
3
4
 
 
				connection.commit();
				connection.close();

[Alwin]

Il faut que tu travail sur le pattern Command et en aucun cas essayer de maintenir une transaction sur plusieurs appels à ton servlet !

En gros, toutes les requêtes de modification, tu les empiles dans une liste et tu execute le tout quand tu recois un COMMIT (sans oublier de purger la liste après le COMMIT).

[thc]

merci, je vais regarder cette piste...

je vous tiendrais au courant

a+
chris