Newsgroup: it.comp.java
Titolo: Transazioni annidate all'interno degli EJB

Salve a tutti,
ho un dubbio: se all'interno di un metodo di un EJB con attributo
transazionale SUPPORTED viene invocato un metodo dello stesso EJB con
attributo transazionale REQUIRED, viene o meno cominciata una transazione ?
E nel caso in cui il chiamante abbia attributo NOT_SUPPORTED, cosa
accadrebbe ? L'application server darà errore o il secondo metodo riuscirà
comunque ad avviare una transazione ?
Grazie a tutti !
Scorpio.

 accadrebbe ? L'application server darà errore o il secondo metodo riuscirà
Se non ricordo male not_supported non accetta transazioni quindi se da 
lì si richiama un metodo-ejb dovrebbe dare errore.
bye
DKano

 ha scritto nel messaggio
news:giYVd.3952$WC1....@tornado.fastwebnet.it...

Ti ringrazio molto... ho eseguito un po' di test addizionali e i risultati
mostrano esattamente quello che hai evidenziato tu, con la differenza che
anche i metodi invocati normalmente cercano di utilizzare le
transazioni.......
Scorpio

 transazioni.......
Strano.
Vuoi dire che se hai in un EJB
void uno() {
   ...
   due();
   ...
}
void due() {
   ...
}
quando richiami due() (definito come REQUIRED_NEW) in questo modo lui 
tenta di aprire una nuova transazione? Non dovrebbe fare cosě. Per far 
in modo che due() sia invocato come ejb-metodo bisogna fare cosě:
void uno() {
   ...
   miaRemote.due();
   ...
}
per lo meno questo dovrebbe esser il comportamento standard, a quanto ne 
so.
bye
DKano
PS Che application server usi?

 PS Che application server usi?
IBM Websphere 5.0.2.9.  In effetti il comportamento č controintuitivo, anche
se non č cosě assurdo: il metodo "due" ha un certo attributo transazionale
che a priori il container non puň ignorare...Supponiamo che nel codice
si abbia
void uno()
{
     ejb.due(); // 1)
     due();  //2)
}
A rigore di logica la prima chiamate *dovrebbe* richiedere una invocazione
attraverso i meccanismi RMI-IIOP specificati da EJB, la seconda, invece,
no.Perň, come č noto, molto spesso gli application server tendono ad
introdurre ottimizzazioni atte ad evitare il ricorso ad RMI soprattutto se
gli ejb sono co-located, ed indubbiamente una chiamata interna come quella
descritta č un ottima candidata per ottimizzazioni di tal genere.
Le  istruzioni 1) e 2) come vengono effettivamente interpretate dal runtime
?  Non mi parrebbe eretico il fatto che vengano risolte *salvando* il
context transazionale, come se fossero davvero delle chiamate "pure" tramite
interfaccia remota / locale...
Perň le mie sono solo ipotesi...
Scorpio.

 introdurre ottimizzazioni atte ad evitare il ricorso ad RMI soprattutto se
Le ottimizzazioni dell'application server sono "problemi suoi", nel 
senso che non mi possono (o non mi dovrebbero) alterare il comportamento 
dei metodi... Comunque il motivo per avere 2 comportamenti diversi c'e':
mettiamo il caso che per determinati oggetti sia necessario aprire una 
nuova transazione col metodo due() e per altri no; oppure che serva 
stabilire al momento del lancio dell' AS (con una property, ad es.) se 
aprire la nuova transazione o meno o, ancora, due() deve poter esser 
usato come sotto-metodo di uno() nella stessa transazione oppure 
chiamato direttamente da remote in una nuova transazione.
Il problema si risolve appunto usando o il metodo 'diretto' o quello 
tramite remote/local. Per cui io mi aspetterei comunque un comportamento 
diverso nei due casi...
Io non so esattamente cosa ci sia scritto nello standard j2ee ma a 
logica dovrebbe venir differenziato il comportamento a seconda del tipo 
di chiamata.
Per citare altri AS, bea (6.1) si comporta come dico io (transazionale 
se chiamato da remote/local, no se chiamato direttamente)
bye
DKano

 DKano
Sicuramente il tuo ragionamento è più che valido, m'informerò con cura,
eventualmente cercando lumi direttamente con IBM.
Per intanto grazie per il tuo parere.
Scorpio.