Newsgroup: it.comp.java
Titolo: Entity Ejb

Ciao
Vorrei sapere se un Entity effettua una query al Db ogni volta che chiamo il
metodo findByPrimaryKey (ovviamente con la stessa chiave) oppure la fa solo
alla prima chiamata e poi li salva in strutture dati interne?
Se la risposta giusta è la seconda, allora come farebbe ad accorgersi se
cambio quel record (= Entity) da un sistema esterno?

accorgersi se cambio quel record (= Entity) da un sistema esterno?
Dipende dal tipo di transazione in cui la modifica avviene,
e (in ambiente clustered) dalla politica di update del server.
-- 
Life's something u don't get out alive..
ObjectZone - 
http://space.tin.it/computer/csadun

 ha scritto nel messaggio
news:9pkd72$gse$1...@news.mch.sbs.de...


 wrote in message
news:9pkd72$gse$1...@news.mch.sbs.de...


 2) il db non deve essere toccato da nessun'altro all'infuori dell'entity ...
su questo non mi sento di essere d'accordo, ma forse non ti ho capito:
la consistenza deve essere garantita cmq anche a fronte di modifiche
operate da altre fonti.
Se invece l'accesso fosse esclusivo da parte dell'ejb, sarebbe proprio
il caso in cui il container potrebbe implementare una politica di
caching per le query (alla quale ti dici contrario nel punto 1), o no?
-- 
Ciao,  |     Gott weiss ich will kein Engel sein
Matteo |                     -- Rammstein, Engel

 caching per le query (alla quale ti dici contrario nel punto 1), o no?
La specifica degli ejb dalla versione 1.1 in poi delega l'isolamento dei
dati al Db o meglio:
riporto un pezzo di Blueprints
... "Non si può modificare il livello d'isolamento di un entity bean con
persistenza container managed. Questi bean usano quello di base del DBMS
che, solitamente, è READ_COMMITTED. Per entity bean con persistenza bean
managed e per tutti i session beans, si può scegliere il livello d'
isolamento da programma con le API date dal gestore del DBMS. Per esempio,
un DBMS potrebbe permettere di leggere datti non registrati (uncommitted)
invocando il metodo setTransactionIsolation:
Connection conn;
.....
.....
conn.setTransactionIsolation(TRANSACTION_READ_UN COMMITTED);
.....
" ...
La consistenza di cui parli e tutto il resto rientra nell'ACID della
transazionalita' degli ejb che sono solo CMT. (Container Managed
Transaction) .. dove pero' la I= isolamento lo gestisce il Db .... quindi
credo, anzi sono sicuro di aver ragione......
Dai che mi piace questo argomento ... .dimmi cosa ne pensi .... e se ho
sbagliato meglio cosi' avro' imparato qualcosa di nuovo.
Ciao


 sbagliato meglio cosi' avro' imparato qualcosa di nuovo.
penso che e' piu' probabile che sugli ejb impari qualcosa io! ;-)
quindi a te la parola...
-- 
Ciao,
Matteo

 toccato solo dall'entity. Come dire: "mi suona strano" (non voglio dire che
Scusate se m'intrometto con un osservazione terra-terra...
Pensa che figo :) : hai un bell'entity in memoria, view di un record su
sistema persistente, e questo viene modificato esternamente tramite un
qualsiasi tool di gestione (tipo SQL plus di Oracle per intenderci...):
chi usa l'entity (quindi o un Session EJB oppure qualsiasi client
abilitato a farlo) si trova a maneggiare dati inconsistenti, addio ACID.
Ma si sa...le vie del signore sono infinite...
Ciao ciao 
Giuseppe

 
ok, magari ripassero' gli ejb prima di continuare questo thread, ma
ejbLoad() non serve -fra l'altro- proprio a questo?  O il container non
se ne accorge e non lo invoca sugli ejb da sincronizzare?  :-/
devo trovare il tempo di fare una prova...


 se ne accorge e non lo invoca sugli ejb da sincronizzare?  :-/
Purtroppo penso che il container non sia così inteligente da
accorgersi......
l' ejb load ricarica i dati ma solo dopo aver utilizzato per le modifiche al
db gli ejb...
almeno questo è quanto fà il jboss.. lo sto studiando riga per riga....
certo che è una figata, passatemi il termine ; )
ciao, marco