[J2EE] Stateless Session Bean uniek voor elke gebruiker? *

Pagina: 1
Acties:

  • Casteloni
  • Registratie: November 2001
  • Laatst online: 02-05 20:41
Voor een applicatie maak ik nu gebruik van een Statefull Session Bean die een bepaald rapport genereerd. Achteraf gezien kan dit naar mijn mening best wel een Stateless Session Bean worden, aangezien hij toch maar 1x gebruikt wordt in een JSP pagina.

Het is belangrijk dat elke gebruiker en eigen SessionBean heeft op het moment dat deze gebruikt wordt. Als 10 gebruikers een rapport opvragen moeten er ook 10 Session Beans zijn. Na de ejbCreate worden een aantal methodes gebruikt die een aantal acties uitvoeren ( alleen getters ) en vervolgens is het klaar.

Nu kwam ik in de J2ee Tutorial het volgende stukje tegen:
Because stateless session beans can support multiple clients, they can offer better scalability for applications that require large numbers of clients. Typically, an application requires fewer stateless session beans than stateful session beans to support the same number of clients.
Betekent dit dus dat een gebruiker per definitie niet een unieke SessionBean heeft? Elke gebruiker krijgt wel een referentie naar een SessionBean door middel van een ejbCreate.

Aangezien het vrij belangrijk is dat dit zo blijft en ik niet ergens iets kan vinden over hoe hier mee omgegaan wordt hoop ik dat iemand hier wat meer over kan vertellen.

  • Bbfreak
  • Registratie: September 2002
  • Laatst online: 04-02 10:03
Gezien het aantal gebruikers en de functionaliteit van je Session Beans denk ik dat ze overkill zijn.
Een Statefull Session Bean is ervoor om een status vast te houden.
Ik begrijp je verhaal niet helemaal maar ik denk dat dit niet veel is.
Kijk daarom eens naar HttpSession objecten. Zijn goedkoper, sneller en bieden goede functionaliteit. Het kan zijn dat ik je bericht verkeerd begrijp hoor.
Session Beans bevatten meestal ook Business Processes dus dat gaat lastig in een HttpSession object maar dan moet je altijd proberen om Stateless Session Beans te gebruiken omdat deze toch een groot voordeel hebben bijvoorbeeld op de performance.
Ik hoop dat ik je een beetje in de goede richting stuur anders hoor ik het wel.

Twitter @cmeerbeek / Halo Waypoint Profile


  • Casteloni
  • Registratie: November 2001
  • Laatst online: 02-05 20:41
De session bean wordt gebruikt om een rapport op te bouwen. Vervolgens wordt vanuit een JSP pagina een aantal keer een methode aangeroepen ombijvoorbeeld een URL op te vragen voor een plaatje.

De reden dat ik hierover ben gaan nadenken is dat ik problemen krijg bij het passivaten van mijn bean. Opzich hoeft hij helemaal geen state vast te houden (1x aanmaken, een aantal methodes aanroepen ) en verder wordt hij niet meer gebruikt. Vereiste is wel dat deze uniek is per gebruiker.

Ik zie in dat ik al deze informatie in een Struts Action kan afhandelen en deze vervolgens in de Request scope te plaatsen. Echter dit is zo een rigoreuze verandering dat ik dit niet wil doen. Na wat verder bestuderen van de J2EE specs denk ik toch dat een stateless bean geen goed idee is.
Because all instances of a stateless session bean are equivalent, the container can choose to delegate a client-invoked method to any available instance. This means, for example, that the container may delegate the requests from the same client within the same transaction to different instances,
Ik creeer een instantie / referentie naar een Stateless Session Bean voor Persoon A. Het rapport wordt opgebouwd. Deze referentie stop ik in de request scope, en vervolgens forward ik naar de jsp pagina.Persoon A begint met het aanroepen van een aantal methoden op de Session Bean om het rapport te tonen.

Ondertussen wilt persoon B het rapport ook zien en die wilt ook een instantie van de Stateless Session Bean. Echter JBoss besluit om deze niet opnieuw aan te maken en geeft hem de instantie die persoon A gebruikt.

Resultaat: Persoon B zou de plaatjes zien die bij Persoon A horen.

Klopt het scenario zoals ik deze hierboven omschreven heb? Mocht performance dus een issue worden, dan zou ik de BL naar de StrutsAction moeten verplaatsen, maar dat is ook niet wenselijk.