La stratégie de génération d'ID est essentielle pour l'insertion par lots dans Hibernate. En particulier, la génération d'IDENTITÉ ne sera généralement pas work (notez que AUTO correspond généralement à IDENTITY également). En effet, lors de l'insertion par lots, Hibernate a un indicateur appelé "requiresImmediateIdAccess" qui indique si les ID générés sont immédiatement requis ou non ; si c'est le cas, le traitement par lots est désactivé.
Vous pouvez facilement le repérer dans les journaux de niveau DEBUG lorsqu'il indique "exécution immédiate de l'insertion d'identité" - cela signifie qu'il a ignoré le traitement par lots car il a été indiqué que les ID générés sont requis immédiatement après l'insertion.
Stratégies de génération qui font généralement work sont TABLE et SEQUENCE, car Hibernate peut pré-générer les ID, permettant ainsi l'insertion par lots.
Un moyen rapide de déterminer si votre insertion par lots fonctionne consiste à activer les journaux de niveau DEBUG, car BatchingBatcher vous indiquera explicitement la taille du lot en cours d'exécution ("Executing batch size:" + batchSize ).
De plus, les propriétés suivantes sont importantes pour réaliser l'insertion par lots. Je n'ose pas dire qu'ils sont nécessaires car je ne suis pas assez expert en Hibernate pour le faire - c'est peut-être juste ma configuration particulière - mais d'après mon expérience, ils étaient néanmoins nécessaires :
hibernate.order_inserts = true
hibernate.order_updates = true
Ces propriétés sont assez mal documentées, mais je pense qu'elles ont permis aux instructions SQL INSERT et UPDATE d'être correctement regroupées pour l'exécution par lots. Je pense que cela pourrait être les inserts multi-rangées que vous recherchez. Ne me tirez pas dessus si je me trompe, je me souviens de mémoire.
Je vais également continuer et supposer que vous définissez la propriété suivante ; sinon, ceci devrait servir de rappel :
hibernate.jdbc.batch_size = xx
Où xx est la taille de lot souhaitée, naturellement.
