tsp-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Tsp-devel] JTSP : le sessionId...


From: Eric NOULARD
Subject: Re: [Tsp-devel] JTSP : le sessionId...
Date: Sun, 27 Mar 2005 17:30:13 +0200

Je suis OK, avec:

TspSession mySession = tspConsumer.openSession(url);
au lieu de

int sessionId = tspConsumer.openSession(url);

C'est une erreur de ma part pour conserver le session id,
c'est à effectivement à l'objet session de le garder pour lui.
Un objet TspSession doit juste pouvoir donner son 'id'
[decapsulage des éléments de specs]
qui correspond à ce que le provider lui a effectivement donné
comme id.

Et cela correspond au fait que TspSession est 100% API N-1.

Eric

Le dimanche 27 mars 2005 à 00:15 -0500, Stephane Galles a écrit :
> Bonjour, bonjour,
> 
> j'étais en train de commencer l'API niveau n  pour JTSP, mais il y a un 
> petit
> détail qui m'est revenu concernant la notion de sessionId actuellement 
> utilisé par
> l'API n-1 . Ma remarque est valable à la fois pour l'API niveau n et 
> n-1, car il n'y
> a pas de raisons de gérer cela différement.
> 
> Actuellement le cycle de vie d'une session est le suivant :
> 
> TspConsumer tspConsumer = new TspConsumer();
> int sessionId = tspConsumer.openSession(url);
> TspSession mySession = tspConsumer.getSession(sessionId);
> [...]
> tspConsumer.closeSession(sessionId);
> 
> Autremement dit, l'objet tspConsumer possède une Map
> de toutes les sessions ouvertes, et on y accède par sessionId. Puis
> quand on veut fermer une session, on s'adresse à monsieur le
> TspConsumer
> 
> Je trouve cela un peu "forcé". D'une part parceque on est dans un
> langage objet, et qu'on a pas besoin d'un objet TspConsumer pour
> gérer la destruction de la session, et d'autre part, proposer un sessionId
> comme handle ne fait que déplacer le problème, car il va bien falloir
> que je mette ces sessionId dans une Map ou liste à moi, pour savoir
> ce qu'ils signifie. Autrement dit, je préfèrerait que l'objet TspConsumer
> ne soit qu'une factory et me laisser gérer mes listes de sessionId
> 
> Je vous propose donc la chose suivante :
> 
> TspConsumer tspConsumer = new TspConsumer();
TspSession mySession = tspConsumer.openSession(url);
> [...]
> mySession.close();
> 
> La plupart des API objet fonctionnent comme cela. La création
> n'est pas de la responsabilité d'un objet, mais sa destruction l'est.
> Exemple classique des drivers JDBC java :
> L'objet Connection se détruit tout seul : 
> http://java.sun.com/j2se/1.4.2/docs/api/java/sql/Connection.html#close()
> Mais la création est faite par :
>  
> http://java.sun.com/j2se/1.4.2/docs/api/java/sql/DriverManager.html#getConnection(java.lang.String,%20java.util.Properties)
> 
> En tout cas, pour tester, je tenter l'API "simple" de cette maniere, on 
> verra
> si on le garde ou pas en fonction de ce que cela donne.
> 
> 
> 
> 
> 
> _______________________________________________
> Tsp-devel mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/tsp-devel
> 





reply via email to

[Prev in Thread] Current Thread [Next in Thread]