Lorsque vous rendez des nouveaux objets persistants, vous devez régulièrement appeler flush() et puis clear() sur la session, pour contrôler la taille du cache de premier niveau.

Session session = sessionFactory.openSession();
Transaction tx = session.beginTransaction();

for ( int i=0; i<100000; i++ ) {
    Customer customer = new Customer(.....);
    session.save(customer);
    if ( i % 20 == 0 ) { //20, même taille que la taille du paquet JDBC
        //flush un paquet d'insertions et libère la mémoire :
        session.flush();
        session.clear();
    }
}

tx.commit();
session.close();

Pour récupérer et mettre à jour des données les mêmes idées s'appliquent. En plus, vous avez besoin d'utiliser scroll() pour tirer partie des curseurs côté serveur pour les requêtes qui retournent beaucoup de lignes de données.

Session session = sessionFactory.openSession();
Transaction tx = session.beginTransaction();

ScrollableResults customers = session.getNamedQuery("GetCustomers")
    .setCacheMode(CacheMode.IGNORE)
    .scroll(ScrollMode.FORWARD_ONLY);
int count=0;
while ( customers.next() ) {
    Customer customer = (Customer) customers.get(0);
    customer.updateStuff(...);
    if ( ++count % 20 == 0 ) {
        //flush un paquet de mises à jour et libère la mémoire :
        session.flush();
        session.clear();
    }
}

tx.commit();
session.close();

Alternativement, Hibernate fournit une API orientée commande qui peut être utilisée avec des flux de données pour et en provenance de la base de données sous la forme d'objets détachés. Une StatelessSession n'a pas de contexte de persistance associé et ne fournit pas beaucoup de sémantique de durée de vie de haut niveau. En particulier, une session sans état n'implémente pas de cache de premier niveau et n'interagit pas non plus avec un cache de seconde niveau ou un cache de requêtes. Elle n'implémente pas les transactions ou la vérification sale automatique (NdT : automatic dirty checking). Les opérations réalisées avec une session sans état ne sont jamais répercutées en cascade sur les instances associées. Les collections sont ignorées par une session sans état. Les opérations exécutées via une session sans état outrepasse le modèle d'événements d'Hibernate et les intercepteurs. Les sessions sans état sont vulnérables aux effets de modification des données, ceci est dû au manque de cache de premier niveau. Une session sans état est une abstraction bas niveau, plus proche de la couche JDBC sous-jacente.

StatelessSession session = sessionFactory.openStatelessSession();
Transaction tx = session.beginTransaction();

ScrollableResults customers = session.getNamedQuery("GetCustomers")
    .scroll(ScrollMode.FORWARD_ONLY);
while ( customers.next() ) {
    Customer customer = (Customer) customers.get(0);
    customer.updateStuff(...);
    session.update(customer);
}

tx.commit();
session.close();

Notez que dans le code de l'exemple, les intances de Customer retournées par la requête sont immédiatement détachées. Elles ne sont jamais associées à un contexte de persistance.

Les opérations insert(), update() et delete() définies par l'interface StatelessSession sont considérées comme des opérations d'accès direct aux lignes de la base de données, ce qui résulte en une exécution immédiate du SQL INSERT, UPDATE ou DELETE respectif. De là, elles ont des sémantiques tres différentes des opérations save(), saveOrUpdate() et delete() définies par l'interface Session.

Comme déjà discuté avant, le mapping objet/relationnel automatique et transparent est intéressé par la gestion de l'état de l'objet. Ceci implique que l'état de l'objet est disponible en mémoire, d'où manipuler (en utilisant des expressions du langage de manipulation de données - Data Manipulation Language (DML) - SQL) les données directement dans la base n'affectera pas l'état en mémoire. Pourtant, Hibernate fournit des méthodes pour l'exécution d'expression DML de style SQL lesquelles sont réalisées à travers le langage de requête d'Hibernate (Chapitre 14, HQL: Langage de requêtage d'Hibernate).

La pseudo-syntaxe pour les expressions UPDATE et DELETE est : ( UPDATE | DELETE ) FROM? EntityName (WHERE where_conditions)?. Certains points sont à noter :

Par exemple, pour exécuter un UPDATE HQL, utilisez la méthode Query.executeUpdate() (la méthode est données pour ceux qui sont familiers avec PreparedStatement.executeUpdate() de JDBC) :

Session session = sessionFactory.openSession();
Transaction tx = session.beginTransaction();

String hqlUpdate = "update Customer c set c.name = :newName where c.name = :oldName";
// ou String hqlUpdate = "update Customer set name = :newName where name = :oldName";
int updatedEntities = s.createQuery( hqlUpdate )
        .setString( "newName", newName )
        .setString( "oldName", oldName )
        .executeUpdate();
tx.commit();
session.close();

Par défaut, les statements HQL UPDATE, n'affectent pas la valeur des propriétés Section 5.1.7, « version (optionnel) » ou Section 5.1.8, « timestamp (optionnel) » pour les entités affectées; ceci est compatible avec la spec EJB3. Toutefois, vous pouvez forcer Hibernate à mettre à jour les valeurs des propriétés version ou timestamp en utilisant le versioned update. Pour se faire, ajoutez le mot clé VERSIONED après le mot clé UPDATE.

Session session = sessionFactory.openSession();
Transaction tx = session.beginTransaction();
String hqlVersionedUpdate = "update versioned Customer set name = :newName where name = :oldName";
int updatedEntities = s.createQuery( hqlUpdate )
        .setString( "newName", newName )
        .setString( "oldName", oldName )
        .executeUpdate();
tx.commit();
session.close();

Notez que les types personnalisés (org.hibernate.usertype.UserVersionType) ne sont pas supportés en conjonction avec le statement update versioned statement.

Pour exécuter un HQL DELETE, utilisez la même méthodeQuery.executeUpdate():

Session session = sessionFactory.openSession();
Transaction tx = session.beginTransaction();

String hqlDelete = "delete Customer c where c.name = :oldName";
// or String hqlDelete = "delete Customer where name = :oldName";
int deletedEntities = s.createQuery( hqlDelete )
        .setString( "oldName", oldName )
        .executeUpdate();
tx.commit();
session.close();

La valeur du int retourné par la méthode Query.executeUpdate() indique le nombre d'entités affectées par l'opération. Considérez que cela peut ou pas corréler le nombre de lignes affectés dans la base de données. Une opération HQL pourrait entraîner l'exécution de multiples expressions SQL réelles, pour des classes filles mappées par jointure (NdT: join-subclass), par exemple. Le nombre retourné indique le nombre d'entités réelles affectées par l'expression. Retour à l'exemple de la classe fille mappée par jointure, un effacement d'une des classes filles peut réellement entraîner des suppressions pas seulement dans la table qui mappe la classe fille, mais aussi dans la table "racine" et potentillement dans les tables des classes filles plus bas dans la hiérarchie d'héritage.

La pseudo-syntaxe pour l'expression INSERT est : INSERT INTO EntityName properties_list select_statement. Quelques points sont à noter :

Un exemple d'exécution d'une expression INSERT HQL :

Session session = sessionFactory.openSession();
Transaction tx = session.beginTransaction();

String hqlInsert = "insert into DelinquentAccount (id, name) select c.id, c.name from Customer c where ...";
int createdEntities = s.createQuery( hqlInsert )
        .executeUpdate();
tx.commit();
session.close();