Mises à  jour batch

en bloc à  de nombreuses
mises à  jour. Supposons, par exemple, qu’une importante société souhaite que ses
nouvelles recrues commencent à  travailler un lundi. Il faudrait alors traiter
de nombreuses mises à  jour (ici des insertions) dans la base de données des employés
en de nombreuses opérations. On a bien sûr tout intérêt à  créer un batch de mise
à  jour que l’on soumettra une seule fois à  la base de données.

La mise à  jour batch améliore considérablement les performances quand
il faut procéder en bloc à  de nombreuses mises à  jour

On distingue deux types de mises à  jour batch, selon qu’elles utilisent des objets
Statement ou PreparedStatement. Même si les mises à  jour batch utilisant des objets
PreparedStatement améliorent les performances, nous commencerons par la version
Statement, plus simple.
La première chose à  faire est de désactiver auto commit qui, par défaut, est activé
dans JDBC. Auto commit signifie simplement que les éventuelles mises à  jour apportées
à  la base de données sont validées après traitement de chaque instruction SQL.
Si l’on veut traiter un groupe d’instructions comme un groupe fonctionnel, il
n’est pas souhaitable que la base de données valide chaque instruction individuellement.
Si l’on ne désactive pas auto commit et si une instruction au milieu du batch
est défaillante, on ne peut pas revenir en arrière au début du batch pour recommencer
l’opération. La moitié des instructions auront abouties. De plus, le travail supplémentaire
de validation de chaque instruction dans un batch demande plus de ressources.
Pour désactiver auto commit, on donne le nom setAutoCommit à  la méthode Connection
et on lui transmet la valeur false.
Une fois auto commit désactivé, on peut créer un objet Statement standard de la
manière habituelle. Au lieu d’exécuter des instructions avec des méthodes comme
executeUpdate, on les ajoute au batch avec la méthode addBatch. Après avoir ajouté
toutes les instructions souhaitées au batch, on peut les exécuter toutes avec
la méthode executeBatch. On peut aussi annuler à  tout moment avec la méthode clearBatch.
L’exemple suivant montre ces méthodes à  l’oeuvre :

connection.setAutoCommit(false);
Statement statement =
connection.createStatement();
statement.addBatch(« INSERT INTO TABLEX « 
« VALUES(1, ‘Cujo’) »);
statement.addBatch(« INSERT INTO TABLEX « 
« VALUES(2, ‘Fred’) »);
statement.addBatch(« INSERT INTO TABLEX « 
« VALUES(3, ‘Mark’) »);
int [] counts = statement.executeBatch();
connection.commit();

Observons qu’un tableau de ints a été renvoyé à  partir de la méthode executeBatch.
Ce tableau contient une valeur int pour chaque instruction exécutée dans le batch.
Si des valeurs sont insérées dans la base de données, la valeur de chaque instruction
sera de 1 (en supposant la réussite). Mais certaines des instructions peuvent
être des instructions de mise à  jour qui affectent des lignes multiples. Si on
place dans le batch des instructions autres que Insert, Update ou Delete, on obtient
une exception.
Un batch preparedStatement est semblable au batch Statement. Cependant, un batch
preparedStatement fonctionne toujours à  partir de la même instruction  » préparée
« , et l’utilisateur ne modifie que les paramètres de l’instruction. Voici un exemple
de code qui utilise un batch preparedStatement :

connection.setAutoCommit(false);
PreparedStatement statement =
connection.prepareStatement(
« INSERT INTO TABLEX VALUES(?, ?) »);
statement.setInt(1, 1);
statement.setString(2, « Cujo »);
statement.addBatch();
statement.setInt(1, 2);
statement.setString(2, « Fred »);
statement.addBatch();
statement.setInt(1, 3);
statement.setString(2, « Mark »);
statement.addBatch();
int [] counts = statement.executeBatch();
connection.commit();

Un autre aspect important des mises à  jour batch se produit quand un appel de
executeBatch échoue, provoquant un nouveau type d’exception appelé BatchUpdateException.
Cette exception, qui est une sous-classe de SQLState, permet d’appeler les méthodes
traditionnelles pour recevoir les messages, le SQLState et code fournisseur. BatchUpdateException
fournit également une méthode appelée getUpdateCounts qui renvoie un tableau int.
Le tableau int contient les nombres de mises à  jour en provenance de toutes les
instructions du batch qui ont été exécutées jusqu’à  l’endroit où la défaillance
s’est produite. La longueur du tableau indique l’instruction en erreur dans le
batch. Ainsi, si le tableau renvoyé dans l’exception a une longueur de trois,
la quatrième instruction du batch est en erreur. Par conséquent, l’objet BatchUpdateException
renvoyé fournit de nombreux renseignements : nombre de mises à  jour pour toutes
les instructions réussies, instructions défaillantes, et tous les détails sur
le problème.

En les prenant par petites doses, les nouvelles fonctions de JDBC 2.0
sont intuitives et plutôt simples à  utiliser

A l’heure actuelle, les deux types d’exécutions, mises à  jour batch ou instruction
par instruction, sont à  peu près équivalentes. Mais il vaut mieux coder selon
le nouveau modèle quand c’est possible, car il y a une grande marge d’optimisation,
compte tenu des informations que le batch Statement met à  la disposition des drivers
JDBC.
Notons que la spécification JDBC 2.1 est disponible depuis peu. JDBC 2.0 et JDBC
2.1 présentent quelques différences subtiles dans la manière dont le comptage
des mises à  jour renvoyées fonctionne lorsque des conditions d’erreurs surviennent
pendant l’exécution du batch. Les drivers JDBC AS/400 actuels supportent JDBC
2.0.