[EJB3] applicatie brede variable

[Bastiaan V]

hey hoi,

Ik ben bezig met een ejb3 applicatie met een web-frontend, nu kan ik alleen 1 ding niet vinden...

Ik moet namelijk een (1) variable beschikbaar hebben voor alle gebruikers. Nu ben ik (uiteraard) al wezen googlen, en heb ook het o'reilly ejb3 boek (een aanrader) er op nagezocht.

'een variable' is nogal vaag dus ik zal een klein voorbeeldje geven;

Stel je hebt een forum gemaakt in ejb3, nu moet een admin het hele forum in 'onderhouds mode' kunnen zetten. nu is het grote probleem dat bij zowel statefull en stateless sessionbeans er meerdere beans in een pool komen waarbij de client er 1 krijgt toegewezen. als de admin deze aanpast is dit alleen aangepast in _die_ bean, waardoor de clients er geen weet van hebben.
Natuurlijk zou ik er voor kunnen kiezen om de status in de DB op te slaan, maar dit lijkt me overbodig omdat het niet belangrijk is dat de status bewaard word bij een herstart van de app-server.

iemand een idee?

/edit

de variable moet dus bewaard blijven in de buisness logic layer, en niet in de web-layer...

natuurlijk zou ik een klasse kunnen maken met een singleton, maar dat lijkt me ook een hack-oplossing (al kan ik niet concreet zeggen waarom )

[ Voor 11% gewijzigd door Bastiaan V op 12-09-2006 23:05 ]

[MTWZZ]

Waarom geen Singleton, die dingen zijn er voor bedoeld om iets 1 keer te maken wat daarna voor alles gebruikt kan worden.
Ik gebruik zelf in mijn apps (C# wel) vaak Singletons voor de configuratie zodat wanneer je configuratie veranderd gelijk alle threads ed over die nieuwe waarde beschikken.

[Tubby]

natuurlijk zou ik een klasse kunnen maken met een singleton, maar dat lijkt me ook een hack-oplossing (al kan ik niet concreet zeggen waarom )

Ik denk dat alle oplossingen die je bedenkt om het SingleTon pattern te vermijden onder hack-oplossingen vallen

[ Voor 4% gewijzigd door Tubby op 13-09-2006 14:25 ]

[The - DDD]

Singleton in een EJB container...
Sure... deploy de applicatie nu maar is op een cluster. Singleton op een EJB omgeving is wat mij betreft een van de meer ranzige truukcs die je toe kan passen. Sowieso is het hele singleton pattern iets waarvan je ernstig na moet denken of je dat onding uberhaupt wel een pattern wil noemen. Singleton is een van de missers in het GOF boek wat mij betreft en iedereen gebruikt het ding maar gewoon omdat het het meest simpele pattern is wat in het boek staat.

Niet doen dus. De enige oplossing die je hebt is het gegeven extern van je EJB container opslaan. Dus in een database. Of op een soort cache.

Eigenlijk wil je dit helemaal niet oplossen in je EJB container. Die dingen horen zich met business logica te belasten en niet met UI gerelateerde "we zijn in onderhoud" pagina.

Beste is volgens mij tijdelijk een redirect te plaatsen op je front-end server/loadbalancer. Al het verkeer re-direct je dan naar een statische pagina. Een kale pagina serveren is iets wat zelfs de meest kale webserver bij zou moeten kunnen benen. Als je een single server setup hebt werkt het ook nog steeds prima. Gewoon redirecten naar een alternatieve pagina.

[ Voor 20% gewijzigd door The - DDD op 13-09-2006 14:31 ]

[MTWZZ]

The - DDD schreef op woensdag 13 september 2006 @ 14:30:
Singleton in een EJB container...
Sure... deploy de applicatie nu maar is op een cluster. Singleton op een EJB omgeving is wat mij betreft een van de meer ranzige truukcs die je toe kan passen. Sowieso is het hele singleton pattern iets waarvan je ernstig na moet denken of je dat onding uberhaupt wel een pattern wil noemen. Singleton is een van de missers in het GOF boek wat mij betreft en iedereen gebruikt het ding maar gewoon omdat het het meest simpele pattern is wat in het boek staat.

Onzin IMHO. Het singleton pattern zal ongetwijfeld misbruikt worden maar dat gebeurt met alles software, hardware en vorken ook als we er toch over bezig zijn.
Zoals ik al aangaf heb ik dit alleen in C# apps gebruikt en is dat natuurlijk niet 1-op-1 over te nemen, het was alleen een suggestie.

[momania]

Op een single server omgeving zou je de servlet context kunnen gebruiken.

[Bastiaan V]

het is als ik de racties hier goed begrijp niet mogelijk om binnen EJB een object te hebben waarbij je zeker bent dat alle clients _hetzelfde_ object gebruiken (zonder een passivate ) ?

[momania]

EJB 'hoort' niet bij je client applicatie, maar je client applicatie maakt er gebruik van. Het centraal vastleggen van een gegeven dat voor de client applicatie van belang is voor zijn gedrag, hoor je dus niet eens via EJB te doen (ook al was het mogenlijk)

[ Voor 3% gewijzigd door momania op 13-09-2006 20:43 ]

[The - DDD]

MTWZZ schreef op woensdag 13 september 2006 @ 14:55:
[...]


Onzin IMHO. Het singleton pattern zal ongetwijfeld misbruikt worden maar dat gebeurt met alles software, hardware en vorken ook als we er toch over bezig zijn.
Zoals ik al aangaf heb ik dit alleen in C# apps gebruikt en is dat natuurlijk niet 1-op-1 over te nemen, het was alleen een suggestie.

Probleem van een singleton is dat het niets minder is dan een dikke vette global variabele. Iets waar we met OO juist zo ons best voor doen om vanaf te komen. Naar mijn idee kun je singletons eigenlijk altijd voorkomen door een beetje nadenken. Singleton is eigenlijk altijd luiheid van de ontwikkelaar om effe makkelijk gegevens over en weer te kunnen gooien.

[Verwijderd]

In een bredere context is er mischien de vraag met welk mechanisme je zo snel mogelijk een message kan broadcasten naar alle aanwezige clients in je systeem.

[MTWZZ]

The - DDD schreef op woensdag 13 september 2006 @ 22:04:Probleem van een singleton is dat het niets minder is dan een dikke vette global variabele. Iets waar we met OO juist zo ons best voor doen om vanaf te komen. Naar mijn idee kun je singletons eigenlijk altijd voorkomen door een beetje nadenken. Singleton is eigenlijk altijd luiheid van de ontwikkelaar om effe makkelijk gegevens over en weer te kunnen gooien.

Uit jouw laatste zin begrijp ik dat je dus voor elk object dat over een configuratie setting wil beschikken een complete instantie van je configuratie object? En op die manier dus ook de complete onderliggende resources (filestream, database connectie, etc) ook instantieert. Dus zeggen dat een singleton alleen maar een dikke vette globale variabele is, is IMNSHO een oversimplificatie.

Om weer even on-topic te gaan:

Beste is volgens mij tijdelijk een redirect te plaatsen op je front-end server/loadbalancer. Al het verkeer re-direct je dan naar een statische pagina. Een kale pagina serveren is iets wat zelfs de meest kale webserver bij zou moeten kunnen benen. Als je een single server setup hebt werkt het ook nog steeds prima. Gewoon redirecten naar een alternatieve pagina.

Dit is denk ik de beste oplossing, geen gedoe om de implementatie van je site te wijzigen en zoals hierboven opgemerkt, dit kan _elke_ webserver.

[Verwijderd]

MTWZZ schreef op donderdag 14 september 2006 @ 13:45:
[...]

Uit jouw laatste zin begrijp ik dat je dus voor elk object dat over een configuratie setting wil beschikken een complete instantie van je configuratie object? En op die manier dus ook de complete onderliggende resources (filestream, database connectie, etc) ook instantieert. Dus zeggen dat een singleton alleen maar een dikke vette globale variabele is, is IMNSHO een oversimplificatie.

Om weer even on-topic te gaan:

[...]

Dit is denk ik de beste oplossing, geen gedoe om de implementatie van je site te wijzigen en zoals hierboven opgemerkt, dit kan _elke_ webserver.

Praktisch is dat voor de TS het beste, maar dit topic ging over een "applicatie brede variable". Deze zal dus best wel een paar keer komen bovendrijven in een search naar dit onderwerp en het is dus mischien wel aardig als hier toch een antwoord op komt.

[Michali]

The - DDD schreef op woensdag 13 september 2006 @ 22:04:
Probleem van een singleton is dat het niets minder is dan een dikke vette global variabele. Iets waar we met OO juist zo ons best voor doen om vanaf te komen. Naar mijn idee kun je singletons eigenlijk altijd voorkomen door een beetje nadenken. Singleton is eigenlijk altijd luiheid van de ontwikkelaar om effe makkelijk gegevens over en weer te kunnen gooien.

Een Singleton heeft heel weinig van de problemen van een globale variabel. Bij een Singleton heb je overzicht over wat er gebeurt met de gegevens. Je kunt dat controleren via de methoden van de class. Bij een globale variabel heb je het probleem dat je er vanuit alle hoeken van de applicatie wat mee kan doen, zonder er controle over te hebben. Ik ben wel met je eens dat je deze pattern niet te veel moet gebruiken, en dat hij teveel misbruikt wordt, maar het kan in sommige gevallen een goede oplossing zijn (waarmee ik niet beweer dat het ook voor dit probleem is, daar weet ik helaas te weinig van af).

[Verwijderd]

Michali schreef op donderdag 14 september 2006 @ 19:09:
[...]
Een Singleton heeft heel weinig van de problemen van een globale variabel. Bij een Singleton heb je overzicht over wat er gebeurt met de gegevens.

Overzicht is maar 1 aspect van de problemen. In zekere zin vind ik het argument zelfs niet eens zo valide. Stel dat ik iets doe van Singleton.set("bla"); en globalvar.value = "bla"; bij allebij kan ik tracen welke code wat er mee doet of er in de IDE een breakpoint opzetten als de de method wordt aangeroepen resp. de variable veranderd.

Het enige wat je bij de eerste kunt doen is het gedrag van de setter globaal in 1 keer veranderen. In Java kan je aan een directe instance data assignment geen listener oid hangen.

Een probleem wat singletons (als je ze op deze manier gebruikt) overeen hebben met globale variabelen is IMO meteen het grootste probleem: als je ooit eens van je code die de singleton gebruikt meerdere instanties tegelijk wilt gaan draaien (bv in meerdere threads) dan koppelen ze wel allemaal naar diezelfde singleton. Dit was in de jaren 90 -het- probleem met de standaard C lib (bv met het globale error nummer). Of je de globale var nu achter een method verstopt of niet, maakt voor het probleem dat meerdere instanties er ongewild naar koppelen niet uit.

Daarom is het vaak veel slimmer om je code slechts indirect van een singleton gebruik te laten maken: gooi bovenop het singleton pattern nog het factory pattern. Je code koppelt dan weliswaar statisch naar die factory maar deze kun je, wanneer nodig, verschillende objecten terug laten geven (bv op basis van thread ID) zodat verschillende instanties van de code met verschillende instanties van de 'singleton' kunnen werken.

Of anders gezegd, bij een verkeerd gebruik van de singleton propageerd de singleton eigenschap zich over een groot gedeelte van je andere code dat helemaal geen singleton hoeft te zijn.

[The - DDD]

Ja, maar om een singleton te implementeren zul je moeten synchronizen. En dat mag je volgens de ejb spec dus niet doen.

Verder noemt iemand een configuratie item ophalen vanaf een filestream. Lees de spec er maar op na, het File object valt onder een verboden package.

Ik heb het tot nu toe niet gezegd om anderen de kans te geven het te bedenken. Maar jongens kom op nou. EJB's wat heeft iedere applicatie server tot zijn beschikking en is bij uitstek het gekozen mechanise om configuratie in op te slaan en globaal beschikbaar te zijn?

Een directory service.

[ Voor 3% gewijzigd door The - DDD op 15-09-2006 06:29 ]

[Bastiaan V]

momania schreef op woensdag 13 september 2006 @ 20:42:
EJB 'hoort' niet bij je client applicatie, maar je client applicatie maakt er gebruik van. Het centraal vastleggen van een gegeven dat voor de client applicatie van belang is voor zijn gedrag, hoor je dus niet eens via EJB te doen (ook al was het mogenlijk)

met client doel ik op de client applicatie (in dit geval een web applicatie, maar t had net zo goed een rich client app kunnen zijn welke de ejb's aanspreekt.
Dis is naar mijn mening ook het hele idee achter ejb. alle buisness logica in de ejb's zodat de clients zich daar geen zorgen over hoeven te maken (en er daardoor gemakkelijk verschillende soorten clients gemaakt kunnen worden)

The - DDD schreef op woensdag 13 september 2006 @ 22:04:
[...]


Probleem van een singleton is dat het niets minder is dan een dikke vette global variabele. Iets waar we met OO juist zo ons best voor doen om vanaf te komen. Naar mijn idee kun je singletons eigenlijk altijd voorkomen door een beetje nadenken. Singleton is eigenlijk altijd luiheid van de ontwikkelaar om effe makkelijk gegevens over en weer te kunnen gooien.

dat is dus de probleemstelling waar ik een antwoord op zoek

Verwijderd schreef op woensdag 13 september 2006 @ 23:13:
In een bredere context is er mischien de vraag met welk mechanisme je zo snel mogelijk een message kan broadcasten naar alle aanwezige clients in je systeem.

broadcasten is niet eens nodig, de client(s) zullen gewoon (via een session bean) een lookup doen naar de status van deze 'globale var'.

Alle oplossingen welke zeggen dat ik het op moet lossen in de presentatie laag of zelfs de request op moet vangen in de evt. loadbalancer zijn natuurlijk helemaal smerige oplossingen. Dit vooral omdat er meer zal moeten gebeuren dan een rederect naar een errorpage.

Omdat ik denk dat de vraagstelling nog niet erg duidelijk is, hier de opzet.

De client, webapp, rich client of van mijn part een webservice opent een verbinding met de applicatie. Er word dus een session bean gemaakt voor deze client en er word een response gegeven.
Deze response geeft de inhoud weer van variable 'foo', welke bij het opstarten van de applicatie de waarde '0' heeft gekregen.
Nu maakt een andere client een verbinding. Voor deze client word ook een session bean aangemaakt. deze 2e client zet de variable 'foo' naar '1'. Nu zou client nummer 1 bij een refresh een 1 moeten weergeven, wat dus niet gebeurt, omdat deze een eigen instatntie van de session bean heeft.

Hou hierbij in gedchten dat client1 een web app kan gebruiken, en client 2 een rich client gebruikt (Swing?).

[The - DDD]

In de database als je het mij vraagt.