[DB2][JDBC] Comment libérer des fichiers ouverts par une connexion JDBC ?

[la7su]

Bonjour à tous,

Je cherche à comprendre ce qui se passe sur une base DB2 lors de l'exécution répétée d'une requête SQL effectuée via un driver JDBC (librairie JT400).
Voici le code très simple que j'exécute :

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
 
...
Class<AS400JDBCDriver> clazz = (Class<AS400JDBCDriver>) Class.forName("com.ibm.as400.access.AS400JDBCDriver");
AS400JDBCDriver driver = clazz.newInstance();
Properties props = new Properties();
props.setProperty("user", login);
props.setProperty("password", password);
props.setProperty("autoReconnect", "true");
 
AS400 as400 = new AS400("as400so1", login, password);
connection = driver.connect(as400);
connection.setTransactionIsolation(READ_COMMITTED);
connection.setAutoCommit(true);
st = connection.prepareStatement(MA_REQUETE);
res = st.executeQuery();
res = st.executeQuery();
...

La requête est un select très simple (select * from UNE_TABLE). Elle est exécutée volontairement 2x de suite.

Via la commande wrkactjob sbs(qusrwrk), je visualise les travaux actifs, puis les fichiers ouverts pour le job qui m'intéresse.
La première exécution de la requête ne tient aucun fichier ouvert, mais dès la seconde, le fichier correspondant à la table sur laquelle porte la requête est maintenu ouvert jusqu'à la fermeture de la connexion à la base.
Mes questions sont donc les suivantes : qu'est-ce qui fait que le fichier est maintenu ouvert ? Et comment libérer les fichiers ?

Merci d'avance pour votre aide !

[K2R400]

La première fois quand tu fais une requête, l'optimiseur construit son plan d'accès (le stocke dans le cache et dans ton cas dans un package *SQLPKG) puis créé l'ODP (Open Data Path).
A la fin de la première exécution, l'ODP est supprimée. C'est ce que l'on appelle un HARD CLOSE ou un FULL OPEN, comme tu voudras.

A la seconde exécution, toujours plus rapide que la première car le plan d'accès étant créé, il fabrique à nouveau l'ODP (FULL OPEN) puis cette fois-ci, pour des raisons de performances ne la supprime pas (PSEUDO CLOSE)
A la troisième exécution c'est encore plus rapide, pas de plan d'accès ni d'ODP à créer.

Ta table n'est pas vraiment vérouillée comme tu le prétends.
Elle peut être sauvegardée voire réorganisée, mais ça dépend de ta version.

Pourquoi veut-il libérer la table ?

Il y a très peu de moyens pour "libérer" les tables.
D'abord sache que chaque ODP ouverte (pseudo close) après une requête "ne prend" environ que 1 Mo de mémoire. Mais multiplié par nombre de curseur/requête et de jobs, je te l'accorde ça peut vitegrimper.

Tu peux "tuer" toutes les ODP en utilisant :

Code :

ALCOBJ OBJ((BIB/MATABLE *FILE *EXCL)) CONFLICT(*RQSRLS)

Tu peux aussi dans ton programme, fermer la connexion ou utiliser les ordres SQL : DISCONNECT, RESET

Mais à mon humble avis, utiliser les pseudo close est un gage de performances, il faudrait juste savoir pourquoi veux-tu libérer le tout.

[punkoff]

Bonjour,

J'ai fais un +1 sur K2R400 par contre je penses ne pas être d'accord sur un point avec lui.

Je ne vois pas pourquoi un close connexion implique une suppression des odp.

Pour moi les odp vont dégager quand le job associé à la QZDASOINIT va ce finir.

De plus si votre code tourne sur un serveur d'application, il faut systématiquement faire une fermeture de la connexion quand vous avez récupéré votre resultSet.
Sinon vous risquez d'avoir une saturation des connexions utilisé par votre appli.

edit : ci-joint un exemple de code Java http://www.code400.com/viewsamples.php?lang_id=19

[la7su]

Tout d'abord, merci pour vos réponses.

Pour tenter de répondre à un point de punkoff

Pour moi les odp vont dégager quand le job associé à la QZDASOINIT va ce finir.

et vérifier si j'ai bien compris, la connexion est le job associé à la QSDASOINIT, donc quand la connexion est fermée, le job se termine.

Ensuite, voici des explications supplémentaires quant aux raisons de ce post.
Le coeur de nos produits est fait de programmes RPG. Nos avons développés ces dernières années des modules JEE périphériques. Aujourd'hui, un de nos clients rencontrent le problème suivant : un de nos modules JEE ouvre un certains nombres de connexions et les maintient ouvertes (normal puisqu'on utilise un pool de connexion) mais cela engendre un gros ralentissement des programmes RPG. Dès que les connexions (donc les jobs associés) sont killées/fermées, tout redevient normal.

Une piste donnée par IBM était de modifier le paramétrage de l'isolation de transaction (READ_UNCOMMITTED par défaut) et de tester avec les autrs valeurs READ_COMMITTED, REPEATABLE_READ, SERIALIZABLE.
C'est en réalisant ce test, que je me suis aperçu de ce comportement "bizarre" de mon point de vue (pas de fichier ouvert avant la seconde exécution d'une requête).
D'après les explications de K2R400, je suppose que nous devons jouer sur le paramétrage du pool de connexions (réduire le nombre de connexions inactives maintenues ouvertes), à moins que vous n'ayez d'autres pistes à me soumettre ?

[punkoff]

Si vous étés en read-commited, faites vous bien des commit / rollback ?

l'auto-commit paramétré ce fait à quel moment ?

edit: ok je n'utilise pas le bon vocabulaire, donc je vais m'abstenir de parler sur ce thread car j'ai peur de vous faire perdre du temps.

J'ai confondu la cloture de connexion et cloture de statement :

What does "Limit on number of statements exceeded" mean?
A Toolbox Connection object can manage only a finite number of open Statements at any given time. If this maximum is exceeded, an SQLException will be thrown with the message "Limit on number of statements exceeded." This usually happens when a JDBC program neglects to close Statement objects that are no longer needed. The solution is to close Statement objects when they are no longer needed. This is generally a good idea anyway, since it helps to conserve resources on both the client and the IBM i system.

"The limit is 9999 open Statements per Connection."

http://www-03.ibm.com/systems/i/soft...dbc.html#faqB6