Newsgroup: it.comp.java
Titolo: Ejb statfull , realizzazione carrello della spesa

Sto studiando gli ejb e mi sono sorte un po di domande nel momento in cui ho
pensato di realizzare un carrello della spesa (tipo sito e-commerce) ,
cercando di rispettare il paradigma MVC.
I dubbi che mi sono sorti e che vi  rigiro sono :
1) Se ho un database sotto la mia applicazione dove conservo la
disponibilità dei miei prodotti come gestisco le transazioni?
2) Se realizzo delle jsp dinamiche che mantengano aggiornata la visione ai
client della disponibilità dei prodotti devo fare delle chiamate dirette
dalle jsp all
ejb , ma non rispetterei le linee giuda della Sun.Se interpongo un Bean
(come sarebbe mia intenzione) alla commit (quindi al cambiamento effettivo
della disponibilità dei prodotti sul database) dovrei fare in modo che
aggiorni pure il Bean ma poi come lo comunico alla jsp di modo da aggiornare
la visione??
Ringrazio a priori tutti coloro mi vogliano dare qualche suggerimento.

 wrote in message
news:1LW88.43501$nI1.1...@twister1.libero.it...


 ha scritto nel messaggio
news:a41ds8$195p$1...@newsreader1.mclink.it...


 
No, il Session Bean Stateful non e' adatto per fare il carrello della 
spesa, contrariamente a quanto molti pensano. Anzi, e' un tipico modo di 
cacciarsi nei guai.
Usa l'entity, o non usare gli EJB
uL

 > entity di modo da renderla meno pesante e più prestazionale(se dico


 essere più adatto e consigliato uno Stateful?
In effetti sono stato troppo stringato: un ejb stateful non e' adatto a 
fare uno shopping cart "persistente". Se ti basta un shopping cart 
banale, va benissimo.
Il problema e' che spesso si parte cosi' e poi si prova a fare in modo 
che i dati persistano, siano un a sorta di cache per il dB, e tutto cio' 
non funge. I Session Stateful servono per tenere traccia ad esempio del 
cammino fatto da un cliente all'interno di un sistema, o in generale 
cose che se vanno perse non faccinao decadere la funzionalita' del 
sistema ma si possono tranquillamente resettare ed eventualmente 
ricominciare.
Visto che uno shopping cart persistente e' IMHO fondamentale per la 
professionalita' di un sistema di ecommerce, ecco perche' in generale e' 
sconsigliato. E comunque uno shopping cart analogo si puo' fare con 
HttpSession. Chiaramente se si parla di web e di interfaccia 
servlet/jsp, l'utilita' degli Stateful Session diminuisce ancora 
(poiche' hai a disposizione HttpSession)
HTH
uL

 ha scritto nel messaggio
news:3C651427...@flashnet.it...


 delete ed update a raffica sul db.
- Se hai un'interfaccia web, usa HttpSession e le performance sono 
ancora migliori, altrimenti se e' un'applicazione non web il Session 
Stateful va bene. E ricorda che il session Stateful e' pesantissimo, 
anche piu' dell'Entity in molte condizioni di lavoro classiche.
- Se hai bisogno di persistenza, non hai invece scelta che l'Entity.
Quali sono i casi in cui invece, anche avendo a disposizione HttpSession 
(interfaccia web), il Session Stateful ha il suo uso?
P.S.
Alcuni pattern sono proprio per migliorare le performance di 
un'applicazione distribuita, non per peggiorarle.
uL

 uL


 servlet/jsp
Anche se si parla di web, personalmente, mi piace molto di più uno stateful
sb che non un javabean in sessione. O, come hai detto tu, un entity.

 (interfaccia web), il Session Stateful ha il suo uso?
Va bene, ma allora cosě non finiamo per abolire gli stateful sb? in un
sistema di e-commerce il carrello della spesa č un oggetto di business, cosě
io ho sempre pensato che fosse molto meglio far sě che risieda su EJB
container che non sul web server. Di sicuro, come tu dici si perde un po'
piů in performance, ma mi č successo varie volte di switchare un JavaBean di
sessione in uno Stateful SessionBean perché mi pareva piů sensato che stesse
con gli altri oggetti di business. Ho fatto male?
Ciao
Luigi

 tempi di attesa...
Gli entity sfruttano il meccanismo di instance pooling e di cache dal db, e
la sincronizzazione degli accessi avviene solo se più utenti accedono alla
stessa entità (ovvero lo stesso record). Il che non succede perché due
utenti diversi non dovrebbero avere lo stesso carrello della spesa.
Per il resto del messaggio, ho più o meno il tuo punto di vista.
Luigi.

 soltanto in readonly ho migliorato di molto le performances..
Gli Entity in effetti possono portare a molti problemi. Un modo per non 
investire troppo tempo in skill EJB e tortuosita' varie degli 
application server j2ee, e' quello di utilizzare solo gli stateless, che 
garantiscono sclabilita' e non tendono grosse trappole al povero 
sviluppatore j2ee
comunque, ecco un bell'articolo di Tyler Jewell sull'argomento:
http://www.onjava.com/pub/a/onjava/2001/10/02/ejb.html
Su 
www.theserverside.com
 ci sono stati diversi followup.
uL

 Va bene, ma allora cosě non finiamo per abolire gli stateful sb? 
In effetti gli stateful sono stati inizialmente pensati come equivalente 
di HttpSession per sistemi non web. Non e' che non abbiano utilizzi, 
solo non moltissimi quanto puo' sembrare.
ciao,
uL

 prepartita, cosa c'e' di meglio? :)))
Forza J...ava !!! :))

 ha scritto nel messaggio
news:3C66C995...@flashnet.it...


 2) Che tipo di Entity un CMP?
In genere è preferibile un CMP, quando non si ha a che fare con un database
legacy.

 ha scritto nel messaggio
news:a497m6$rs9$1...@pegasus.tiscalinet.it...


 
Non credo proprio... dipende da un sacco di fattori
ciao
uL

 ha scritto nel messaggio
news:20X98.2439$tv6....@twister1.libero.it...


 
no, fai lo stateless.
ciao
uL

 ha scritto nel messaggio
news:20X98.2439$tv6....@twister1.libero.it...
