Discussion :

[libuma]

Bonjour,

Dans mon application web, lorsque l'utilisateur est enregistré et clique ensuite sur déconnexion, la connexion à la DB(oracle) est fermée et la session est invalidée.
On se retrouve donc avec 0 curseur ouvert dans la DB pour cet utilisateur.

Cependant, si celui-ci, plutôt que de se déconnecter proprement, clique sur la croix de la fenêtre (explorateur web), les curseurs restent ouverts.

Y-a-t-il une solution pour contrer se problème ? détecter que l'utilisateur n'est plus connecté?

Merci d'avance.

[spopoff]

Bonjour,

Le retour du client / serveur ... Une bonne architecture serait de mutualiser la connexion Oracle, mais ce n'est sans doute pas possible (licence, authentification ...).

• Une solution serait de récupérer l'événement de fermeture de Windows et se brancher sur le code de fermeture (je fais souvent cela avec des applis VBA).
• Une autre solution c'est de rendre la croix inactive et donc de forcer l'utilisateur à utiliser votre bouton de fermeture.

Dans les applis vba j'utilise le code suivant pour bloquer l'usage de la croix, il faudrait trouvé le moyen de l'appliquer à une fenêtre navigateur, il faut aussi trouver le moyen de faire tourner ce code côté client, mais comme c'est du client / serveur pas difficile de faire un déploiement:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
 
Private Declare Function RemoveMenu Lib "user32" (ByVal hMenu As Long, ByVal nPosition As Long, _
ByVal wFlags As Long) As Long
Private Declare Function GetSystemMenu Lib "user32" (ByVal hwnd As Long, ByVal bRevert As Long) As Long
Private Declare Function FindWindow Lib "user32.dll" Alias "FindWindowA" (ByVal lpClassName As String, _
ByVal lpWindowName As String) As Long
Private Const MF_BYPOSITION = &H400&
 
Les déclarations sur l'API windows
et son utilisation:
Private Sub UserForm_Initialize()
    Dim lHwnd As Long
    lHwnd = FindWindow("ThunderDFrame", Me.Caption) 'Change to match your userforms caption
    Do While lHwnd = 0
        lHwnd = FindWindow("ThunderDFrame", Me.Caption) 'Change to match your userforms caption
        DoEvents
    Loop
    RemoveMenu GetSystemMenu(lHwnd, 0), 6, MF_BYPOSITION 'When using by position, 6 represents the 7th menu item (including separators)
End Sub

Salutations

[juridakus]

Cependant, si celui-ci, plutôt que de se déconnecter proprement, clique sur la croix de la fenêtre (explorateur web), les curseurs restent ouverts.

Y-a-t-il une solution pour contrer se problème ? détecter que l'utilisateur n'est plus connecté?
Merci d'avance.

En travaillant avec des cookies (Encore faudrait il que le client les accepte) dont tu en contrôle l'existence tu peux détecter une fermeture intempestive du navigateur client. Sinon il faut faire des règles organisationnelles pour l'utilisation de ton application (Forcer les utilisateurs à avoir les bonnes habitudes ou les pénaliser coté serveur).

[fr1man]

Je ne suis pas certain d'avoir tout compris, en tout cas, il ne faut pas laisser de connexions ouvertes comme cela en espérant que ton utilisateur va les fermer.
Les connexions doivent être fermées après utilisation et réouvertes pour une nouvelle demande. Tu peux passer par un pool de connexions pour une meilleure gestion.

[libuma]

Je ne suis pas certain d'avoir tout compris, en tout cas, il ne faut pas laisser de connexions ouvertes comme cela en espérant que ton utilisateur va les fermer.
Les connexions doivent être fermées après utilisation et réouvertes pour une nouvelle demande. Tu peux passer par un pool de connexions pour une meilleure gestion.

C'est justement le but...
Trouver le moyen de fermer toutes les connexions.

@Spopoff: Malheureusement, il m'est impossible via Java de modifier le comportement de la fermeture d'une fenêtre IE.

@juridakus: ça me parait une bonne piste, je vais déjà voir si c'est pratiquable dans notre environnement. Mais cela veut dire exécuter des scripts de contrôle tous les X temps ?

[fr1man]

A chaque demande d'infos qui arrive sur ton serveur, tu fais tes traitements, tu prépares la réponse et tu fermes tes connexions.
Ce n'est pas comme cela que tu procèdes, non ?

[Air P-E]

Si au bout d'un certain temps, aucune requête n'est faite par l'utilisateur tu peux fermer les connexions. Tu peux pas le gérer côté Oracle ? Sinon en Java mais bon...

[libuma]

A chaque demande d'infos qui arrive sur ton serveur, tu fais tes traitements, tu prépares la réponse et tu fermes tes connexions.
Ce n'est pas comme cela que tu procèdes, non ?

Si.
Je procède comme ceci :
Appel de la procédure dans une méthode.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
 
 
ArrayList rights= new ArrayList();
OracleCallableStatement cstmt = (OracleCallableStatement)cn.prepareCall ("{call OWNER.PACKAGE.PROCNAME (?)}");					
// Declare that the outparam cursor
cstmt.registerOutParameter (1, OracleTypes.CURSOR);
// Do the call
cstmt.execute ();
// Get the RS
ResultSet rs = (ResultSet)cstmt.getObject(1); 
// Trought the RS : 
while(rs.next())
{	
    rights.add(rs.getString("MY_FIELD"));
}
rs.close();
rs=null;
cstmt.close();
cstmt = null; 
 
return rights;

Ensuite lorsque j'interroge la vue v$open_cursor, j'obtiens

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
select sql_text from v$open_cursor where user_name = 'MY_CURRENT_USER';
-> BEGIN OWNER.PACKAGE.PROCNAME (:1); END;

[fr1man]

Il faut aussi fermer tes connexions, en plus de tes resultset et statements.
Tu devrais aussi placer la fermeture dans un bloc finally.
Tu peux utiliser un pool de connexions, pour optimiser la récupération de connexion.

[libuma]

Il faut aussi fermer tes connexions, en plus de tes resultset et statements.
Tu devrais aussi placer la fermeture dans un bloc finally.
Tu peux utiliser un pool de connexions, pour optimiser la récupération de connexion.

Tout à fait d'accord pour le bloc finally, c'est ce que j'utilise.
Par contre, fermer à chaque fois ma connexion ?
Ca veut dire que quelque part, il faut stocker le mot de passe de l'utilisateur, qu'il faut s'identhifier et clôturer la connexion à chaque page visitée ?
ça me parait un peu lourd.

Actuellement, la connexion est créée à l'authentificiation de l'utilisateur et est gardée en session.


En sachant que chaque utilisateur utilise un identifiant et un mot de passe différent pour se connecter à la DB, est-ce qu'un pool de connexion permet d'apporter un plus ?

Il me semble que le but d'un pool de connexion est lorsqu'on le "close()", il ne se ferme pas mais est remis à disposition pour un autre utilisateur, hors ici, il ne peut utiliser la connexion d'un autre utilisateur. Pas de partage possible.

D'après moi, je ne peux utiliser ceci que pour l'utilisateur générique qui permet la demande de nouvel utilisateur/oubli de mot de passe.

[libuma]

bis

[fr1man]

Déjà c'est assez rare de gérer les droits d'une application par les droits de la BD.
On utilise généralement un user générique en base de données, et on gère les droits au niveau applicatif.
Je ne connais pas tes besoins, tu dois avoir de bonnes raisons de procéder comme cela.

Pour le pool de connexion, rien ne t'empêche de récupérer une connexion dans le pool en fournissant le user et mot de passe.
Ce qui est sur, c'est que c'est une très mauvaise idée de garder une connexion ouverte par user tout au long de leur navigation. Tu fais comment si tu as 500 utilisateurs connectés en même temps ?

[libuma]

C'est vrai que ça commence à faire pas mal de connexions, curseurs ouverts.
Nous disposons d'un large volume mais il est préférable de traiter le mal avant qu'il n'agisse
D'où ce post.

Mais donc, si l'on procède comme tu le décris, avec un pool de connexion, cela veut dire que je devrai garder en mémoire le mot de passe de l'utilisateur tout au long de sa connexion, non ?

[fr1man]

Oui si tu dois le fournir pour récupérer ta connexion.

[libuma]

Oui si tu dois le fournir pour récupérer ta connexion.

N'obtient-on pas là une sécurité moins facile à gérer ?
Balader le mot de passe tout au long du surf de l'utilisateur..

Aussi, les performances ne sont-elles pas moins bonnes étant donné qu'on rajoute une ouverture et une fermeture de connexion à chaque changement de page ?

[fr1man]

N'obtient-on pas là une sécurité moins facile à gérer ?
Balader le mot de passe tout au long du surf de l'utilisateur..

Oui c'est pour cela que je t'expliquais que normalement, on utilise un user générique pour la base de données.

Aussi, les performances ne sont-elles pas moins bonnes étant donné qu'on rajoute une ouverture et une fermeture de connexion à chaque changement de page ?

Non puisque l'on passe par un pool.
C'est ta méthode qui à terme donnera de mauvaises performances.

[libuma]

Je vois, merci pour vos réponses.

Sachant qu'il ne m'est pas envisageable de changer tout le processus pour utiliser un user générique, pensez-vous que cela vaut la peine de quand même passer par un pool de connexions?

Si oui, comment assurer une bonne sécurité tout en baladant le mot de passe ? oO

[OButterlin]

Passer par un pool pour ça, bof, pas vraiment...

Ceci dit, c'est rarissime dans une application web d'établir une connexion par utilisateur, qu'est ce qui justifie cette méthode ?

Si vraiment, tu peux utiliser un listener sur la session, paramétrer assez bas le timeout de la session (quitte à faire une activation périodique via ajax pour la "stimuler") et nettoyer à ce moment ta connexion.
Ceci dit, ça reste du niveau de la bidouille
(sans compter que dans le principe, je n'adhère pas l'ouverture d'une connexion par utilisateur... mais bon, tu t'en fiches je pense )
La détection de la fermeture de la fenêtre n'étant pas possible directement, je ne vois pas d'autre alternative, mais peut-être que quelqu'un d'autre en aura une

[fr1man]

Quel est le problème avec les pools ?

[libuma]

A chaque servlet vous ouvrez et fermez votre connexion à la db.

Pour savoir si l'utilisateur s'est authentifié, vous baladez dans la session un statut "connecté" ou quelque chose du style alors ?