Hibernate pour une application massivement parallele

Salut a tous,

Je souhaite utiliser Hibernate dans le cadre d'une application industrielle massivement parallèle.

Je me perds, malgré avoir lu toute la doc Hibernate, dans le concept de Session. Typiquement je vais avoir de nombreux threads qui vont instancier puis persister des objets, ce de façon purement parallèle.

Dois je alors utiliser une session par threads et la découper en sous transactions a chaque fois que je désire persister, ou bien dois je utiliser une unique session globale à tous les Threads et utiliser des sous transactions pour chaque threads ?

Je trouve le tuto officiel peu clair sur ce point, pourtant ils disent eux mêmes qu'un mauvais découpage threads/sessions/transactions peut avoir un impact dramatique sur les perfs, d'où mes craintes (je vais quotidiennement persister des millions d'objets dans un vaste système).

Merci à celles et ceux qui sauront m'éclairer.

Effectivement tes questions sont tout à fait légitimes ;) (d'ailleurs si tu n'as pas vu cette page je te conseille d'y jeter un coup d'œil) et voici quelques éléments :

• Tout d'abord je ne suis pas sûr que la classe Session soit threadsafe (mais j'ai toujours entendu dire qu'il fallait que la session ne soit manipulée que par un seul thread). Par contre, une seule et même instance de la classe SessionFactory peut (et doit) être utilisée par l'ensemble de tes threads. A noter que la conf Hibernate permet d'associer directement une session à un thread (en précisant <property name="hibernate.current_session_context_class">thread</property> dans la conf Hibernate).
• En ce qui concerne les performances, il faut savoir qu'Hibernate propose divers mécanismes de cache (2 niveaux plus exactement : le 1er niveau correspond à la session Hibernate et le 2ème qui est global à la JVM et donc "partageable" par tous tes threads). Et donc même si chaque thread utilise sa propre session Hibernate, tu quand même peux utiliser un cache global.
• Dans un contexte d'utilisation de masse je te conseille de lire le chapitre 13 de la doc Hibernate qui présente pas mal d'optimisations de traitement (notamment le paramètre batch-size). D'autre part, il faut que tu fasses attention à la consommation mémoire de ton programme Java (notamment à cause des caches de données qui peuvent "trop" se remplir). Il faut penser à purger régulièrement la session (voir paragraphe 19.3 de la doc Hibernate).
• Par le découpage de tes transactions, il faut déjà tenir compte du SGBD pour être sûr que tu ne lui transmettes pas des volumes de données trop importants. Par contre, as-tu besoin d'utiliser un gestionnaire de transaction ? (par exemple pour gérer des transactions globales multi-bases via JTA/XA par exemple) ou bien penses-tu directement utiliser les transactions JDBC ? Ce genre de chose peut influer sur les performances

Salut MOuLi et merci pour ta réponse.

• Il me semble en effet que la Session Factory utilise le Singleton Pattern. Pour la conf en revanche je n'avais pas compris comme cela le coup de la relation 1-1 entre Threads et Session, remarques si c'est vraiment le cas cela m'arrange pas mal
• Pour les caches je suis habitué à les manipuler, d'ailleurs ils sont déjà en place et l'excellent système de cache plugins d'Hibernate est l'une des raisons qui me pousse à l'utiliser.
• Pour les batchs j'avais lu ça dans la doc, en effet ça me semble indispensable lorsqu'il s'agit de faire des Bulk inserts, donc je m'en servirait naturellement.
• Le découpage des transactions... pour l'instant je n'y ait pas pensé (c'est l'origine du topic). Dans un premier temps la base sera un server Oracle classique, qui en effet recevra d'importantes quantité de données. Mais hormis le coup des batch je n'ai aucune idée de la façon d'optimiser le découpage de mes transactions au sein de chacun des threads responsables de la persitence...

Pour les liens, je les avait aussi parcouru mais ils n'avaient fait que "m'embrouiller" encore plus, je cite: http://www.hibernate.org/42.html

Citation:

---

Unit of Work

A particular unit of work is grouping data access operations. We usually refer to the Hibernate Session as a unit of work because the scope of a Session is exactly that.

[...]

Transactions

Transactions also group data access operations.

---

Déjà on a l'impression que session = (ou presque) transactions... Bref in fine je pense donc plutôt a recuperer une session par thread, et pour chacun à découper en transaction disons de 10 000 opérations (pour faire du batch, chiffre bien sur donné au hasard: d'ailleurs comment connaitre la taille optimale d'un batch ? Je n'ai pas trouvé de référence à ce problème).

Mais cela ne me dis toujours pas en quoi cela serait plus rapide qu'une autre solution ;)

Après reconsultation de la doc Hibernate, je te confirme bien que la session est mono-threadé.

Sinon session et transaction regroupent effectivement des traitements (et dans ce sens, ils peuvent être qualifier d'Unit Of Works). Mais il faut bien voir qu'elles ne répondent pas aux mêmes exigences ni aux mêmes problématiques :

• Pour la session Hibernate, c'est le cache de 1er niveau notamment (mais par contre cela ne signifie rien côté SGBD)
• Pour la transaction, ce sont les propriétés ACID et donc cela a une signification fonctionnelle forte.

Pour ton idée de découpage d'une session avec 1 ou N transactions de 10 000 opérations, pourquoi pas ? Mais il y aura certainement d'autres considérations à prendre en compte (mémoire max utilisable pour ton appli dans la JVM, paramétrage du SGBD, limitations éventuelles du driver JDBC ...) pour qualifier les performances de ton batch. Et puis es-tu sûr qu'il n'y a pas des aspects fonctionnels à prendre en compte ? (pour garantir la cohérence de tes traitements dans une transaction notamment en cas de rollback).