J'ai vu qu'il y avait déjà eu une question dans le forum à ce sujet et que l'on conseillait de lire la doc.

Personnelement, j'ai bien lu la doc mais je dois avouer que tout n'est pas limpide.

Je vais écrire ici ce que j'ai compris. Si quelqu'un pouvait compléter mes explications légères, voire les etayer à l'aide d'un exemple concret, ce serait profitable.

Proxy :

1) En général
Ce design pattern permet de charger en mémoire une version légère de l'objet. L'objet n'est réellement chargé que quand on a besoin de toutes ses fonctionnalités.
L'exemple le plus classique est celui de l'image qui se charge dans un navigateur.
Tant que l'image n'est pas complétement chargée, on présente un rectangle.
<proxy>
<rectangle/>
</proxy>
Puis, une fois l'image chargée.
<proxy>
<image/>
</proxy>
L'intérêt est un gain de mémoire.

2)Appliqué à hibernate, voici ce que j'ai compris.
On charge un objet en mémoire depuis la base de donnée à l'aide d'un session.load ou d'un session.find.
Mais en fait, d'autres objets sont chargés via hibernate dans la même requête http. Plutôt que de tous les charger les uns à la suite des autres, on ne charge que les proxies.
Ce n'est que quand dans le code, l'objet est réellement utilisé, que l'on charge complètement l'objet.
Cela peut même se produire dans requête http postérieure.

Lazy loading : (chargement tardif ou différé)
C'est le moment ou le proxy charge complètement l'objet parce qu'il en a besoin.


Là où j'ai des doutes, c'est sur le déclenchement du chargement. Aussi sur le fait que le chargement peut avoir lieu dans une autre requête http, si on a juste fait un session.load dans la la première requête http et que c'est la deuxième qui exploite l'objet.


Merci d'avance pour votre aide dans la compréhension de ce mécanisme.

ps : pouvez-vous aussi succintement expliquer pourquoi la fermeture de la session doit être encapsulée dans un filtre pour que cela fonctionne ? Quels sont les contraintes à l'emploi de ce chargement tardif.[/b]

Tu as je pense grosso modo compris la chose.

Le concept central qu'il ne faut pas oublier sinon c'est la Session hibernate. C'est une unité de travail. Le chargement tardif d'un objet ne peut se faire que dans la même unité de travail que le load. Si j'ai bien compris ce point, c'est pour des problématiques transactionnelles. Si tu fais un load dans une session (donc une transaction) et que tu charges un proxy et si tu essaies de faire un chargemen tardif dans une autre session (donc transaction). Il se peut que l'objet ou même l'association entre les deux objets ait pu être modifié entre temps et donc tu peux avoir des éléments inconsistants sous la main.

De ce point de vue hibernate est très strict et n'autorise le chargement tardif que dans la même unité de travail. D'où l'utilisation du filtre qui permet juste de conserver la session ouverte tout au long d'une requête http alors que sinon elle pourrait être fermée plus tôt. Ce filtre permet donc de faire du chargement tardif dans la vue.

Le filtre ne permet pas par contre de faire du chargement tardif entre plusieurs requêtes http. Pour cela, il faut réassocier un ancien objet à une nouvelle session pour ensuite avoir le droit de faire du chargement tardif dans la nouvelle session.

L'équipe Hibernate travail en ce moment sur un framework web seam qui semble essayer de solutionner cette problématique via un concept de conversation web. Tu définis une conversation qui va s'étendre sur plusieurs requêtes http et le framework te garantit que ta session va rester ouverte tout au long de ta conversation et tu vas pouvoir faire des chargements tardifs quand tu veux.

Il s'agit d'une problématique centrale dans l'utilisation d'hiberante ou autrement dit : bienvenu dans le monde du lazy loading.