[J2EE] stateful session beans *

Pagina: 1
Acties:

  • R3b3l
  • Registratie: November 2002
  • Laatst online: 15-01 09:20
Hi,

Sinds kort ben ik bezig met J2EE en voornamelijk met EJB. Als eerste projectje (na een heleboel tutorials en voorbeelden) wil ik een login module bouwen. De client-side zal een JSP pagina worden b.v. Login.jsp. Deze submit zijn variablen naar een servlet (loginServlet). Als alles goed gaat met het inloggen zal er voor de klant een stateful session bean aangemaakt worden. Deze session bean zal het centrale aanspreek punt voor de klant worden (session facade pattern).

Ter illustratie, een winkelWagentje.
Een klant logt in, en krijgt een stateful session bean toegewezen. Vervolgens word de klant verwezen naar een pagina, itemToevoegen.jsp. De submit van de jsp word weer afgehandeld door een Servlet (itemToevoegenServlet). Dit servlet gaat er voor zorgen dat het item aan het de session bean word gepresenteerd zodat de session bean de inhoud van het winkelwagentje kan beheren.

Mijn vragen:
Bij het toevoegen van een item in het wagentje, hoe weet itemToevoegenServlet tegen welk session bean hij moet praten? Zal de referentie van de session bean in een HttpSession geplaatst worden? Als dat zo is, waarom zou ik dan ooit stateful session bean gaan gebruiken? Ik kan dan toch alle informatie wel in mijn HttpSession opslaan.

Wie gaat de session time-out regelen? Is dat een HttpSession object of kan dat door de Session bean geregeld worden?

Ik weet dat het allemaal heel makkelijk is, dat ik geen EJB's hoef te gebruiken enz, maar ik vind het een leuk probleempje om mee te beginnen.

Ik geef de voorkeur aan het gebruik van de statefull session bean omdat hij in mijn ogen alle tagen van een HttpSession wel op zich kan nemen. Misbruik ik dan de Session bean?

Alvast bedankt.

Verwijderd

Zal de referentie van de session bean in een HttpSession geplaatst worden?
Ja, inderdaad.
...waarom zou ik dan ooit stateful session bean gaan gebruiken?
Dat is een goede vraag, meestal zal je ook geen statefull bean gebruiken. Maar er zijn 2 redenen te bedenken in jou geval:

1. Je moet je bedenken dat een client niet altijd een session tot zijn beschikking heeft waar de state in opgeslagen kan worden, bijvoorbeeld als jou winkelwagentje wordt beheerd vanuit een webservice. Dan weet je niet wie de client is en of die state kan bewaren. In zo'n geval is het nuttig om het in de session bean te leggen.

2. Wat gebeurt er met het winkel wagentje als de client z'n browser afsluit? Dan is het winkelwagentje ook leeg, tenzij je het op de server bewaart wordt (in een statefull session bean die naar de database schrijft). Als de gebruiker dan de volgende keer terug komt, dan kan hij daarmee verder. Dit is de classic manier van een statefull gebruiken.
Wie gaat de session time-out regelen?
Zoals de naam al aangeeft, de http-session. Want de bean heeft geen weet van zijn client (de session), de relatie ligt alleen van http-session naar de bean.
... misbruik ik dan de Session bean?
Nee hoor, daar is hij voor.

Verwijderd

hmm, ik zou toch eerder een stateless session bean gebruiken die enkel het winkelkarretje persistent opslaat.
Het winkelkarretje zelf houd je dan in je sessie (http) tot je zeker weet dat het persistent opgeslagen moet worden.

ik persoonlijk vind statefull session beans enkel iets om een swing applicatie voor te hangen. Webapplicaties moeten hun eigen state maar bijhouden. iets in je session state stoppen is ook veel sneller dan het winkelwagentje serializeren naar een session bean (en ook nog eens ophalen van de session bean). Ik zou hem zo dicht mogelijk houden bij de kant waar hij van belang is.
browsersessie: zo dicht mogelijk bij de browser
inhoud winkelwagentje besteld: zo dicht mogelijk (liefst in ;)) de database... en voor die ene save hoef je in mijn ogen dan geen stateful session bean.