[Java] SFSB of ...?

[zneek]

Ik ben bezig met een applicatie gebaseerd op Maverick(MVC), Jboss en jsp.

Wanneer een gebruiker inlogt wordt het Gebruiker object in de HttpSession gezet. Elke controller kan er zo bij. Nu moet ik voor database toegang vanuit een DbUtil class een bepaalde eigenschap van de Gebruiker class opvragen. Ik wil niet bij elke DbUtil instantie (elke entiteit heeft zijn eigen DbUtil implementatie) deze eigenschap mee hoeven geven vanuit de aanroepende class.

Ik zat er aan te denken om een StateFullSessionBean te creeeren die de Gebruiker (of alleen die ene eigenschap) heeft. Elke class die behoefte heeft aan de betreffende eigenschap kan de SFSB tevoorschijn toveren en de informatie opvragen die nodig is.

Nu vraag ik me af of dit de "normale" manier is. Ik wil voorkomen dat ik steeds diezelfde eigenschap mee moet geven naar elke class die iets met een DbUtil instantie wil doen. In de HttpSession kijken vanuit de DbUtil is geen optie, aangezien ik dan die elke keer mee moet geven aan de DbUtil. Een SFSB lijkt me dus de meest logische oplossing, alleen vraag ik me af of er ook een non-EJB oplossing voor is?

[edit] De SFSB zou meer info gaan bevatten dan deze ene eigenschap, het gaat hier even om het idee.

[ Voor 5% gewijzigd door zneek op 22-07-2004 16:44 ]

[bigbeng]

Kun je dit niet vrij eenvoudig oplossen met een Singleton implementatie? Dit lijkt mij de non-EJB tegenhanger van de SFSB, of vergis ik me nu sterk?

[zneek]

bigbeng schreef op 22 juli 2004 @ 16:53:
Kun je dit niet vrij eenvoudig oplossen met een Singleton implementatie? Dit lijkt mij de non-EJB tegenhanger van de SFSB, of vergis ik me nu sterk?

Nee. Ik moet per gebruiker iets hebben. Singleton betekent max 1 instantie voor de hele jvm.

[edit] Singleton is eerder de non-EJB variant op een StatelessSessionBean

[ Voor 11% gewijzigd door zneek op 22-07-2004 16:58 ]

[bigbeng]

We begrijpen elkaar niet helemaal denk ik. Ik bedoelde meer iets in de richting van een Singleton class met daarin bijvoorbeeld een lijst met de gebruikers erin. Ala het application object van ASP.

Maar je hebt gelijk wat betreft de SL vs SF, ik geef je nu een stateless oplossing.

[zneek]

ah, ok.

Als dat DE oplossing zou zijn, dan kies ik voor de SFSB oplossing. Dat geeft misschien wat overhead, maar vind ik netter dan alle data voor alle ingelogde gebruikers in 1 lijst zetten.

Een kennis van me kwam met een ThreadLocal verhaal. Daar moet ik nog wat achtergrond info over opzoeken. Dat kan ik nog niet helemaal plaatsen in deze context.

[edit] Mmmm, als ik dit zo lees http://www-106.ibm.com/de...t=grj,l=766,p=threadlocal dan is dat niet eens een zo slecht idee.

[ Voor 22% gewijzigd door zneek op 22-07-2004 19:58 ]

[Verwijderd]

Ik vraag me af wat het grote probleem is met een usercontext door te geven naar de Session laag?
Ik veronderstel dat je een modifier en modification_time veld hebt dat je wil updaten vanuit je dbUtil ofzo? (Security zul je zeker niet in je dbUtil (data??) laag willen afhandelen denk'k zo)

Ik vind het niet hoeven doorgeven van een usercontext echt geen reden om een statefull session bean te gebruiken. Misschien zijn dat gewoon vooroordelen van mijn kant, maar ik denk dat je project betere redenen nodig heeft om SFSB te rechtvaardigen. Het gebeurt (bij mij toch) te snel dat die dingen niet mooi opgeruimd worden en blijven rondslingeren. En tenslotte heb je stateless HTTP voor een webapplicatie waar je iets statefull gaat achtergooien. Niemand weet server-side wanneer de browser session gesloten wordt...

(offtopic, is Maverick goed? Wat zijn zo de voornaamste voordelen tov bijvoorbeeld Struts?)

[zneek]

Verwijderd schreef op 23 juli 2004 @ 08:38:
Ik vraag me af wat het grote probleem is met een usercontext door te geven naar de Session laag?
Ik veronderstel dat je een modifier en modification_time veld hebt dat je wil updaten vanuit je dbUtil ofzo? (Security zul je zeker niet in je dbUtil (data??) laag willen afhandelen denk'k zo)

Ik vind het niet hoeven doorgeven van een usercontext echt geen reden om een statefull session bean te gebruiken. Misschien zijn dat gewoon vooroordelen van mijn kant, maar ik denk dat je project betere redenen nodig heeft om SFSB te rechtvaardigen. Het gebeurt (bij mij toch) te snel dat die dingen niet mooi opgeruimd worden en blijven rondslingeren. En tenslotte heb je stateless HTTP voor een webapplicatie waar je iets statefull gaat achtergooien. Niemand weet server-side wanneer de browser session gesloten wordt...

(offtopic, is Maverick goed? Wat zijn zo de voornaamste voordelen tov bijvoorbeeld Struts?)

Het probleem in het meegeven zit er in dat een hele grote hoeveelheid classes het object in kwestie gaan doorgeven, maar er zelf niets aan hebben. Ik heb nu trouwens een werkbare ThreadLocal oplossing.

Maverick bevalt prima. Ik heb geen ervaring met Struts. Wat me het meest bevalt aan Maverick is de vrijheid. Ik gebruik zowel de XML/XSLT manier en jsp om views te maken. Maverick is zeker de moeite van het bekijken waard.

[Verwijderd]

vergeet niet dat Tomcat bijvoorbeeld (jboss denk'k ook wel) met ThreadPools werkt, en je in een grote applicatie wel eens tegen het probleem kan stoten dat de ThreadLocal nog data uit de vorige call bevat. Dat is geen onoverkomelijk probleem zolang je goed oplet (en ja, statefull session beans kunnen hier sneller voor eenprobleem zorgen

Tja, ik zal er eens naar zien. Ik heb wel al gezien dat je er queues in kan definieren (eerst gewoon XSLT, dan XSL-fo dan PDF bijvoorbeeld gewoon definieren in je config file voor pdf, en gewoon de eerste XSLT voor een andere view...maar ik ben nog niet aan de XSLT )

[zneek]

Verwijderd schreef op 23 juli 2004 @ 13:51:
vergeet niet dat Tomcat bijvoorbeeld (jboss denk'k ook wel) met ThreadPools werkt, en je in een grote applicatie wel eens tegen het probleem kan stoten dat de ThreadLocal nog data uit de vorige call bevat. Dat is geen onoverkomelijk probleem zolang je goed oplet (en ja, statefull session beans kunnen hier sneller voor eenprobleem zorgen

Tja, ik zal er eens naar zien. Ik heb wel al gezien dat je er queues in kan definieren (eerst gewoon XSLT, dan XSL-fo dan PDF bijvoorbeeld gewoon definieren in je config file voor pdf, en gewoon de eerste XSLT voor een andere view...maar ik ben nog niet aan de XSLT )

Op welke manier kun je problemen krijgen met SFSB's dan?

Overigens zet ik in mijn controller een object in een ThreadLocal. Alle aangeroepen classes kunnen er bij, en ik hoef dus niet meer dezelfde variabele overal aan door te geven.

trouwens, dat XSLT gebruik ik bij voorkeur zo min mogelijk. Ik heb 2 XSLTs die een generieke java structuur van Tabel en Form elementen kan omzetten, maar ik maak geen XSLT per view. Veel te kut. Of ik doe het de standaard XSLT of ik maak een jsp view.

[Verwijderd]

tja, ik ga direct zeggen dat het niet al te praktisch onderbouwd is (ben dan ook amar een groentje ).
Maar SFSB heb ik steeds als een geldige oplossing gezien voor bijvoorbeeld SWING applicaties die de handler naar de bean kunnen bijhouden. Achter stateless HTTP hou ik het dan ook op stateless session beans (tenzij je die handler in je session stopt??).
Maar je bent volgens mij bij een webapplicatie niet zeker dat je bean weer mooi ge-ejb-removed wordt. Dus blijf je met enkele instances zitten.

En ik weet niet of een ThreadLocal erbij hoort, maar normaal mag je niets met threads doen in een EJBContainer....en door die threadpooling zou ik daar wel bij opletten. Stel je poolsize staat op 20 en er zijn 35 simultane connecties, dus je threads worden dan zeker hergebruikt, threads waar je je 'usercontext' object aan hebt gehangen...ik weet niet of de mogelijkheid bestaat dat je dan ineens de usercontext van een andere caller opvist...
hoe handelt de container je SFSB call af. Reserveert hij een thread tot de bean geremoved wordt (OK, je usercontext blijft dezelfde) of assigned hij een thread per call naar die SFSB (lijkt me logischer)...
Ik ken de EJB specs niet en nog minder de implementatie van bijvoorbeeld JBoss, maar ik zou persoonlijk geen probleem maken van een usercontext object door te geven. (OK, je moet die usercontext dan elke keer serializen om door te sturen naar je remote bean, maareuhm, zal dat je performantie zo sterk beinvloeden???)

Ik snap van in het begin het probleem niet van de extra parameter in elke signatuur...misschien omdat ik dagelijks op code kijk waar steeds een usercontext of userId wordt doorgegeven (voor security, logging & modifier fields) dat ik het héél normaal vindt....