Database (or system) transaction boundaries are always necessary. No communication with the database can occur outside of a database transaction (this seems to confuse many developers who are used to the auto-commit mode). Always use clear transaction boundaries, even for read-only operations. Depending on your isolation level and database capabilities this might not be required but there is no downside if you always demarcate transactions explicitly. Certainly, a single database transaction is going to perform better than many small transactions, even for reading data.
Une application utilisant Hibernate peut s'exécuter dans un environnement léger n?offrant pas la gestion automatique des transactions
(application autonome, application web simple ou applications Swing) ou dans un environnement J2EE offrant des services de
gestion automatique des transactions JTA. Dans un environnement simple, Hibernate a généralement la responsabilité de la gestion
de son propre pool de connexions à la base de données. Le développeur de l'application doit manuellement délimiter les transactions.
En d'autres mots, il appartient au développeur de gérer les appels à Transaction.begin()
, Transaction.commit()
et Transaction.rollback()
. Un environnement transactionnel J2EE (serveur d'application J2EE) doit offrir la gestion des transactions au niveau du
container J2EE. Les bornes de transaction peuvent normalement être définies de manière déclarative dans les descripteurs de
déploiement d'EJB Session, par exemple. La gestion programmatique des transactions n'y est donc pas nécessaire. Même les appels
à Session.flush()
sont faits automatiquement.
However, it is often desirable to keep your persistence layer portable between non-managed resource-local environments, and
systems that can rely on JTA but use BMT instead of CMT. In both cases you'd use programmatic transaction demarcation. Hibernate
offers a wrapper API called Transaction
that translates into the native transaction system of your deployment environment. This API is actually optional, but we
strongly encourage its use unless you are in a CMT session bean.
Il existe quatre étapes disctinctes lors de la fermeture d'une Session
flush de la session
commit de la transaction
Fermeture de la session (Close)
Gestion des exceptions
La synchronisation de bdd depuis la session (flush) a déjà été expliqué, nous nous attarderons maintenant à la démarcation des transactions et à la gestion des exceptions dans les environnements légers et les environnements J2EE.
Si la couche de persistance Hibernate s'exécute dans un environnement non managé, les connexions à la base de données seront généralement prises en charge par le mécanisme de pool d'Hibernate. La gestion de la session et de la transaction se fera donc de la manière suivante:
// Non-managed environment idiom Session sess = factory.openSession(); Transaction tx = null; try { tx = sess.beginTransaction(); // do some work ... tx.commit(); } catch (RuntimeException e) { if (tx != null) tx.rollback(); throw e; // or display error message } finally { sess.close(); }
Vous n'avez pas à invoquer flush()
explicitement sur la Session
- l'appel de commit()
déclenchera automatiquement la synchronisation (selon le Section 10.10, « Flush de la session » de la session. Un appel à close()
marque la fin de la session. La conséquence directe est que la connexion à la base de données sera relachée par la session.
Ce code est portable est fonctionne dans les environnements non managé ET les environnements JTA.
Une solution plus flexible est la gestion par contexte fourni par Hibernate que nous avons déjà rencontré:
// Non-managed environment idiom with getCurrentSession() try { factory.getCurrentSession().beginTransaction(); // do some work ... factory.getCurrentSession().getTransaction().commit(); } catch (RuntimeException e) { factory.getCurrentSession().getTransaction().rollback(); throw e; // or display error message }
Vous ne verrez probablement jamais ces exemples de code dans les applications; les exceptions fatales (exceptions du système)
ne devraient être traitées que dans la couche la plus "haute". En d'autres termes, le code qui exécute les appels à Hibernate
(à la couche de persistance) et le code qui gère les RuntimeException
(qui ne peut généralement effectuer qu'un nettoyage et une sortie) sont dans des couches différentes. La gestion du contexte
courant par Hibernate peut simplifier notablement ce design, puisque vous devez accéder à la gestion des exceptions de la
SessionFactory
, ce qui est décrit plus tard dans ce chapitre.
Notez que vous devriez sélectionner org.hibernate.transaction.JDBCTransactionFactory
(le défaut), pour le second exemple "thread"
comme hibernate.current_session_context_class
.
Si votre couche de persistance s'exécute dans un serveur d'application (par exemple, derrière un EJB Session Bean), toutes les datasource utilisées par Hibernate feront automatiquement partie de transactions JTA globales. Hibernate propose deux stratégies pour réussir cette intégration.
Si vous utilisez des transactions gérées par un EJB (bean managed transactions - BMT), Hibernate informera le serveur d'application
du début et de la fin des transactions si vous utilisez l'API Transaction
. Ainsi, le code de gestion des transactions sera identique dans les deux types d'environnements.
// BMT idiom Session sess = factory.openSession(); Transaction tx = null; try { tx = sess.beginTransaction(); // do some work ... tx.commit(); } catch (RuntimeException e) { if (tx != null) tx.rollback(); throw e; // or display error message } finally { sess.close(); }
Ou encore, avec la gestion automatique de contexte:
// BMT idiom with getCurrentSession() try { UserTransaction tx = (UserTransaction)new InitialContext() .lookup("java:comp/UserTransaction"); tx.begin(); // Do some work on Session bound to transaction factory.getCurrentSession().load(...); factory.getCurrentSession().persist(...); tx.commit(); } catch (RuntimeException e) { tx.rollback(); throw e; // or display error message }
With CMT, transaction demarcation is done in session bean deployment descriptors, not programmatically, hence, the code is reduced to:
// CMT idiom Session sess = factory.getCurrentSession(); // do some work ...
Dans un EJB CMT même le rollback intervient automatiquement, puisqu'une RuntimeException
non traitée et soulevée par une méthode d'un bean session indique au conteneur d'annuler la transaction globale. Ceci veut donc dire que vous n'avez pas à utiliser l'API Transaction
d'Hibernate dans CMT.
Note that you should choose org.hibernate.transaction.JTATransactionFactory
if you use JTA directly (BMT), and org.hibernate.transaction.CMTTransactionFactory
in a CMT session bean, when you configure Hibernate's transaction factory. Remember to also set hibernate.transaction.manager_lookup_class
. Furthermore, make sure that your hibernate.current_session_context_class
is either unset (backwards compatibility), or set to "jta"
.
The getCurrentSession()
operation has one downside in a JTA environment. There is one caveat to the use of after_statement
connection release mode, which is then used by default. Due to a silly limitation of the JTA spec, it is not possible for
Hibernate to automatically clean up any unclosed ScrollableResults
or Iterator
instances returned by scroll()
or iterate()
. You must release the underlying database cursor by calling ScrollableResults.close()
or Hibernate.close(Iterator)
explicitly from a finally
block. (Of course, most applications can easily avoid using scroll()
or iterate()
at all from the JTA or CMT code.)
Si une Session
lance une exception (incluant les exceptions du type SQLException
ou d'un sous-type), vous devez immédiatement faire le rollback de la transaction, appeler Session.close()
et relâcher les références sur l'objet Session
. La Session
contient des méthodes pouvant la mettre dans un état inutilisable. Vous devez considérer qu'aucune exception lancée par Hibernate n'est traitable. Assurez-vous de fermer la session en faisant l'appel à close()
dans un bloc finally
.
L'exception HibernateException
, qui englobe la plupart des exceptions pouvant survenir dans la couche de persistance Hibernate, est une exception non vérifiée
(Ceci n'était pas le cas dans certaines versions antérieures de Hibernate.) Il est de notre avis que nous ne devrions pas
forcer un développeur à gérer une exception qu'il ne peut de toute façon pas traiter dans une couche technique. Dans la plupart
des applications, les exceptions non vérifiées et les exceptions fatales sont gérées en amont du processus (dans les couches
hautes) et un message d'erreur est alors affiché à l'usager (ou un traitement alternatif est invoqué.) Veuillez noter qu'Hibernate
peut également lancer des exceptions non vérifiées d'un autre type que HibernateException
. Celles-ci sont également non traitables et vous devez les traiter comme telles.
Hibernate wraps SQLException
s thrown while interacting with the database in a JDBCException
. In fact, Hibernate will attempt to convert the exception into a more meaningful subclass of JDBCException
. The underlying SQLException
is always available via JDBCException.getCause()
. Hibernate converts the SQLException
into an appropriate JDBCException
subclass using the SQLExceptionConverter
attached to the SessionFactory
. By default, the SQLExceptionConverter
is defined by the configured dialect; however, it is also possible to plug in a custom implementation (see the javadocs for
the SQLExceptionConverterFactory
class for details). The standard JDBCException
subtypes are:
JDBCConnectionException
- Indique une erreur de communication avec la couche JDBC sous-jacente.
SQLGrammarException
- Indique un problème de grammaire ou de syntaxe avec la requête SQL envoyée.
ConstraintViolationException
- Indique une violation de contrainte d'intégrité.
LockAcquisitionException
- Indique une erreur de verrouillage lors de l'éxécution de la requête.
GenericJDBCException
- Indique une erreur générique JDBC d'une autre catégorie.
One extremely important feature provided by a managed environment like EJB that is never provided for non-managed code is
transaction timeout. Transaction timeouts ensure that no misbehaving transaction can indefinitely tie up resources while returning
no response to the user. Outside a managed (JTA) environment, Hibernate cannot fully provide this functionality. However,
Hibernate can at least control data access operations, ensuring that database level deadlocks and queries with huge result
sets are limited by a defined timeout. In a managed environment, Hibernate can delegate transaction timeout to JTA. This functionality
is abstracted by the Hibernate Transaction
object.
Session sess = factory.openSession(); try { //set transaction timeout to 3 seconds sess.getTransaction().setTimeout(3); sess.getTransaction().begin(); // do some work ... sess.getTransaction().commit() } catch (RuntimeException e) { sess.getTransaction().rollback(); throw e; // or display error message } finally { sess.close(); }
Notez que setTimeout()
ne peut pas être appelé d'un EJB CMT, puisque le timeout des transaction doit être spécifié de manière déclarative.