Newsgroup: it.comp.java
Titolo: Gli EntityBean vanno chiamati attraverso i SessionBean

<<E' buona pratica che gli EntityBean vengano utilizzati attraverso dei
SessionBean. Se un client accedesse direttamente all'entity si ricadrebbe in
una 2-tier application.>>
In una recente applicazione ho fatto uso di EntityBean (chiamando get/set)
da una JSP. Usavo un sessionbean che mi restituiva dei riferimenti ad entity
e questi entity venivano utilizzati dentro la JSP. Ciň č sbagliato?
L'uso di value-objects da alcuni č sconsigliato, poiché si opera su una
"foto" dell'entity, e viene meno il discorso di operare su oggetti "vivi".
Mi sembra che il "Core J2EE Patterns" dica queso se non ricordo male (se sto
ricordando male, controllo su quale altro libro l'ho letto).
Un'altro svantaggio č che estraendo il value object dall'entity si libera
l'entity che puň essere aggiornato in modo asincrono da altri utenti.
In altri termini, correggetemi se sbaglio, per loccare un record che č
visualizzato dentro il browser di un utente, dovrei mettere il riferimento
remoto all'entity in sessione ? (quindi finché la http-session ha un
riferimento all'entity nessun'altro utente puň accedervi)
Questo č un altro errore a cui credo di essere soggetto: sempre in quella
applicazione, mentre i dati sono visualizzati sul browser di un client,
potrebbero benissimo essere aggiornati da qualcun altro, con tutto ciň che
ne consegue.
Ora la mia domanda č: se devo accedere ai servizi applicativi attraverso dei
session bean, č ovvio che devo ricorrere a delle "viste statiche" dei dati
estratti da entitybeans compromettendo anche la mutua esclusione. Se
altrimenti il SessionBean restituisce i riferimenti remoti degli entity allo
strato di presentazione, contraddico il principio del 3-tier (in testa alla
mail).
Sono difronte ad un dubbio Amletico.
Probabilmente sto interpretando male qualcosa...
Please help.
Luigi.

 e questi entity venivano utilizzati dentro la JSP. Ciň č sbagliato?
Ti dň solo un consiglio se devi fare un visualizzazione di dati ti
converebbe
usare JDBC puro.... č piů performante, non ha bisogno di chiamate di rete,
hai il tuo resultset
da scorrere e non centinaia di EJB....
Normalemente mi č stato consigliato di usare entitybeans solo per scrittura
sul DB....
poi bisognerebbe andare a vedere situazione per situazione....
ciao, marco
___________________
Salvador Marco
EXTRAWEB S.r.l
www.extraweb.it

 usare JDBC puro.... č piů performante, non ha bisogno di chiamate di rete,
Credo sia OT perciň ne discutiamo in un'altro thread, ma non sono d'accordo.

 Credo sia OT perciò ne discutiamo in un'altro thread, ma non sono
d'accordo.
Perchè dovrebbe essere OT??
sempre di java stiamo parlando....
e sempre di entity EJB....
cmq come già detto dipende da caso a caso....
ciao, marco

 session bean, è ovvio che devo ricorrere a delle "viste statiche" dei dati


> Perchč dovrebbe essere OT??
intendevo che non risponde esattamente all'interrogativo del post.
Potremmo discutere se usare JDBC sia *sempre* piů performante di usare degli
entity, ma non riguarda quello di cui stavo parlando nel post. So cosa
intendi.
Scusami per la risposta 'sommaria'.

 mail).
Non colgo il nesso: il ValueObject (che puo' essere anche updateable, fra
l'altro) e' consigliato ma non obbligatorio.
uL
-- 
Posted via Mailgate.ORG Server - 
http://www.Mailgate.ORG

> Cosa ne pensi?
Se A è stateful mantiene il riferimento a B e locka il record fino a che il
riferimento ad a non viene perso o viene invocato remove su A.
il punto 4 non è chiaro: nessuno ha messo in sessione B, quindi la JSP non
può rimuoverlo dalla sessione.
Questo è ciò che credo avvenga.

 ha scritto nel messaggio
news:newscache$i9pzpg$ccm$1...@listsrv01.csi.it...


 sull'entity bean A.
Sì credo che le cose avvengano come hai descritto

 l'altro) e' consigliato ma non obbligatorio.
Il fatto è che c'ho un "conflitto" : da una parte mi si dice che non devo
passare entity sul client, perché sarebbe come sviluppare un'applicazione
2-tier, e ciò è sconsigliato. Dall'altra mi si dice che <<Once an object is
resident on the client, it is no longer representative of the data. It is
easy for a client to end up with many dirty copies of the same entity,
resulting in inconsistent processing and representation of data.>>.
Quindi: non posso passare oggetti "in copia" e non posso passare gli oggetti
stessi... questa è l'origine del dilemma.
Probabilmente sto travisando qualcosa, ma è un po' che questa cosa
sonnecchia in qualche angolo della mia testa :)
-Luigi

 l'altro) e' consigliato ma non obbligatorio.



Dovremmo prima definire chi e' il client: nel contesto di una applicazione web sviluppata
con EJB il "client" e' identificabile ad esempio in un SessionBean? 
Ciao,
    Bruno.
---
| Bruno Bossola
| A Java Software Engineer :-)
| 
http://members.xoom.it/bbruno
| 
http://digilander.iol.it/bbossola

Scusate se mi permetto ma credo che non stiate valutando la situazione nel
modo giusto:
Un session, possibilmente stateless, si mette come facciata di un Entity,
soprattutto per diminuire il numero di transazioni all'interno
dell?application Server, e poi per rispettare la regola che la JSP
possibilmente faccia da View ....
Per il Lock del dato bisogna ricordare che:
Nella specifica 1.0 degli EJB, gli Entity che sono sempre CMT (container
managed transaction), potevano sempre gestire la I di ACID (Isolation ...
Level) tramite i descrittori xml e quindi settare il tag isolation level
della transaction a :
READ UNCOMMITTED (la meno sicura, tutto puo' avvenire .... nessun lock)
READ COMMITTED (si possono verificare i Phantom reads, ed gli unrepeatable
reads)
REPEATABLE READ (si possono verificare i Phantom reads)
SERIALIZABLE  (valore di default non si verificano errori di concorrenza)
Con la specifica 1.1 degli ejb, questo non vale piu' ... ma attenzione
alcuni App Server (come Bea weblogic 5.1) non certificato ancora dalla sun e
che segue la 1.1 ... si comporta come la 1.0 .... ;)
Insomma dalla specifica 1.1 in su gli Entity non possono piu' settare il
livello di isolamento nell'xml, ma delegano al DB che di solito e'
Read_Committed......
Poi ci sono alcuni App Server come Bea Weblgic 6.0 che possono dire che un
Entity e' Read Only, oppure Exclusive ..... ma questo non e' standard ....
Quindi prima si settano questi valori, poi si considera se uno sta lavorando
o meno ..... Mi sono Spiegato?
I session che possono essere Bean Managed Transaction, in quel caso nella
specifica 1.1 possono settare sulla classe Connection il metodo, se ricordo
bene, Conn.setTransactionIsolation(Read_Committed...);
Ciao a tutti.
--
Fabrizio Marini
Company Partner
E-mail: 
f.ma...@k-tech.it
E-mail: 
fabry....@mclink.it
K-Tech S.r.l.
Via Tibullo, 13
00193 - Rome (RM) - Italy
Phone: +39 (0) 6 68301467
http://www.k-tech.it
http://www.javaportal.it
http://www.oracleportal.it

 ha scritto nel messaggio
news:a2dut9$hvb$1...@newsreader1.mclink.it...


 wrote in message
news:64z28.20508$tl3.6...@twister2.libero.it...


 ha scritto nel messaggio
news:a2emlv$kjt$1...@newsreader1.mclink.it...
