# Java > Gnral Java > Persistance des donnes >  Architecture d'un client lourd (Swing) avec Hibernate

## nicorama

Bonjour,
Je collabore depuis peu  un projet au travail dans lequel quelque chose me chiffonne.

Il s'agit d'une appli Swing faisant des accs bdd vers un serveur distant, au moyen tantt d'hibernate, tantt de jdbc direct.

Le problme est que les requtes complexes faites avec Hibernate sont extrmement peu performantes, et sont donc remplaces par des requtes SQL.

Je n'ai pas regard en profondeur, mais il apparait clairement que chaque client Swing utilise la session Hibernate sur sa propre JVM.

Hors pour utiliser les capacits de cache d'hibernate, il apparait logique de mettre hibernate ct serveur, et de faire des appels RMI (ou http) entre le client et le serveur. 
Tel que fait actuellement, si deux personnes utilisent l'application en mme temps, ils ne peuvent partager le mme cache. Pire, il y aurait des incohrence sur le client avec des requtes pure jdbc si Hibernate n'a pas flush correctement (je souponne en fait le cache d'tre tout simplement disabled).

Est-ce que mon raisonnement semble logique ? Est-ce que l'on a bien l un anti-pattern ?

----------


## DarkMolo

Salut,

Si j'ai bien compris, les applis Swing client font appel directement au serveur de base de donnes, il n'y a pas d'application au niveau du serveur qui joue l'interface entre les clients et le serveur de base de donne, j'avoue que je n'ai pas encore eu l'occasion de faire de l'hibernate, mais si c'est bien le cas, je crois qu'utiliser Hibernate ou du pure JDBC ne changera rien, puisque chaque client  sa propre connexion directe  la base de donne.




> *nicorama dit:*
> Hors pour utiliser les capacits de cache d'hibernate, il apparait logique de mettre hibernate ct serveur, et de faire des appels RMI (ou http) entre le client et le serveur.


C'est exactement a, quand tu as parl de RMI et http, il devrait y avoir un serveur d'application au niveau du serveur et qui, lui seul devrait accder  la base de donne, c'est lui qui devrait implmenter de l'hibernate ou du JDBC, tous les clients ne se connecteraient que via ce serveur d'application.

Quand je relis ce que j'ai crit, je m'aperois de ne t'avoir rien dit de plus  ::aie:: , au minimum, a up ton problme, en esprant que quelqu'un y voit plus clair.

----------


## arafat877

Salut ;-)
Supposant que nous sommes entrain d'utiliser un client lourd swing communiquant avec un serveur bas Spring Framwork via Spring RMI, qui se connecte avec une petite base de donnes Derby via iBatis.

Pourriez-vous me donner quelques ides sur les accs concurrents, ou bien sur les transactions, et sans oublier que tous les beans implmentes l'interface Serializable, ainsi que toutes les mthodes DAO sont synchronized.

Je veux dire que notre serveur sera accd par plusieurs clients et en rseaux !


Merci d'avance.

Cordialement !

----------


## vhalalla

> Bonjour,
> Hors pour utiliser les capacits de cache d'hibernate, il apparait logique de mettre hibernate ct serveur, et de faire des appels RMI (ou http) entre le client et le serveur.


Bonjour, sauf si vous configur un cache de second niveau (qui souvent n'aura rien de magique), le cache hibernate est ce qu'on appelle le cache de premier niveau qui correspond  la session hibernate.
Comme les diffrents clients n'utilisent pas la mme session Hibernate, dporter hibernate cot serveur ne changera rien  vos performances.

Avant de commencer  regarder ce genrer de chose, a votre place je regarderai a quoi ressemble les requte SQL gnres par hibernate (via un showSql=true). Si les requtes sont trop complexes ou trop nombreuses, cela cache une mauvaise utilisation d'hibernate et le mettre cot serveur ne changera rien.

----------

