La différence ou la relation entre une session utilisateur et une connexion datasource ?

Bonjour,

Je me suis retrouvé un peu perdu suite à une question qu'on m'a posé.

Une entreprise effectue et stock son paramétrages de sessions utilisateurs au niveau de la base de donnée. Comme ils sont en plein migration ils m'ont posé la question sur ce qui va se passer qd ils vont déployer une application Java/ JEE sur un serveur d'applications.
L'application est basée sur un ORM hibernante par exemple.
L'application en général délègue à l'ORM et ce dernier délègue au serveur d'applications la gestion de la datasource et le pool de connexions vers la base de données.
Un utilisateur se connecte à une page de cette application du coup il aura sa session utilisateur créée par le serveur d'applications, quand il effectue une opération qui nécessite d'afficher des données de la base, une connexion va lui être attribué pr effectuer la sélection, et elle sera restitué au pool de connexions ensuite. le même utilisateur va vouloir modifier les données de cette sélection et enregistrer ses modifications en base, il y a très peu de chance qu'il utilise la même connexion précédente ?

Peut on attribuer à une session d'utilisateur la même connexion vers la base de données dans ce cas ? si oui comment ?

le cas de figure est la suivante :

- l'utilisateur se connecte
- sélectionne une liste de produits
- clique sur un de ces produits pr afficher ses détails
- modifie les caractéristiques du produit et les insère en base.

Peut on m'expliquer la relation entre la session utilisateur et les connexions dans un pool de connexion vers une bdd ?


En vous remerciant par avance.

Si tu utilises un pool, ta connexion vers la SGBD est 'anonymisée' donc c'est l'utilisateur de la SGBD associé à ton pool qui effectuera les reqêtes, les resultats seront ensuite retournés à ton application et mis en mémoire dans le thread associé à ta session utilisateur final.

Bonjour,
D'abord merci pour ta réponse.

Je comprends aussi de ta réponse qu'il n'y aucun moyen de surcharger le fonctionnement de pool de connexions afin de lier les connexions de ce dernier aux sessions d'utilisateurs ?

d'avance merci

C'est possible mais ca n'a pas de sens : si tu crées un pool c'est justement pour reutiliser tes connexions. Les lier à une session ne fait que poser des soucis :
* HTTP est un protocol deconnecté (d'où le besoin de session) tu vas donc bloquer une connexion à ton SGBD tant que la session est 'active' (souvent environ 1/2 à 1 h après la dernière requête de l'utilisateur).
* tu vas donc limiter ton nombre d'utilisateurs simultanés au nombre de connexions à ton SGBD
* pour ce que tu décris ca n'a pas de sens sauf si tu utilises la sécurité de la base de données pour controler l'accès ( ce qui est mal) mais là encore tu peux préciser le login/password à utiliser lorsque tu récupères la connexion de la datasource.

Tout est possible, c'est juste que tu pars dans une direction peu courante et qui n'a guère d'intérêt (après cela depend de ton use-case) si on se base sur ce que tu écris.

Je rajoute que si t'associe la connexion à la session, il sera alors impossible de répondre à deux requêtes HTTP en même temps (une connexion n'est pas multithread safe), tu va donc devoir mettre les requetes http en attente (parce que le browser, lui, il va joyeusement requérir en parallèle) et tu va DOS comme un grand ton sserveur J2EE en épuisant son pool HTTP.

Ca va aussi poser problème pour calibrer ton pool de connexion. Rappelons à toutes fins utiles que la taille minimum d'un pool de connexions, pour éviter les deadlocks et l'arrêt du serveur c'est (H*(C-1))+1 , où H est le nombre max de thread HTTP, C est le nombre max de connexions dont aura besoin dans le pire des cas une requête. Si tu associe un connexion à une session, tu va grandiosement exploser la taille de ton pool requis en y ajoutant le nombre max de sessions.

Et d'une manière générale, en plus de poser de gros problèmes techniques (timeout, taille de pool, performances, transactions), ça n'a strictement aucun intérêt.

Si tu élaborais un peu plus sur le pourquoi tu pense avoir besoin de ça, on pourrait t'expliquer "pourquoi tu va t'en passer et c'est mieux ainsi" :)

Donc pour répondre à ta question finale: il y a absolument zéro relation entre la session utilisateur et la connexion DB.

Bonjour,

Merci pour vos réponses.

Description du besoin :

Une entreprise disposant d'une grosse application Oracle Forms datant d'il y a longtemps, ils avaient mis en place un ensemble de paramétrage au niveau de la base de données pour la gestions des accès. Aujourd'hui ils veulent migrer vers une application JEE déployé sur un serveur weblogic. Ils souhaitent exploiter l'existant de l'ancienne application pour réutiliser la sécurité de la base de données pour contrôler les accès.


Par curiosité, pourquoi l'utilisation de la sécurité de la base de données pour contrôler les accès est mal ?

Ce n'est pas mal c'est juste que tu passes d'une application en client-serveur sur ta dabase à une application multi-tiers ;) donc comme tu changes de paradigme tu dois t'adapter.
La sécurité est censée être gérée au niveau du conteneur aka le serveur application ou au niveau de l'application elle-même, si tu la fais gérer par la SGBD alors tu dois gérer l'authentification toi-même.
En fait tu n'as pas besoin d'associer une connexion à ta session http mais juste les credentials d'accès à la SGBD, Datasource a une méthode "getConnection(String username, String password)" pour gérer ton souci.
Après va falloir écrire plein de code à la main : genre

Code:

---

1 2 3 4

Map<String, String> properties = new HashMap<String, String>(); properties.put("javax.persistence.jdbc.user", "user1"); properties.put("javax.persistence.jdbc.password", "user1pwd"); EntityManager em = emf.createEntityManager(properties);

---

bref, bon courage :D

et accessoirement

utiliser un seul compte oracle VS 200 compte oracle. Ca fait une putain de différence sur le tarif annuel :aie:

Dans tous les cas comme expliquer, l'association d'un connexion à un session http est irrelevant à ton problème. Tu as juste besoin d'un connexion pool sans password. Mais forcément une partie des api vont être vachement plus chiantes à gérer comme ça.

Merci bcp pour vos retours bien détaillés.