Newsgroup: it.comp.java
Titolo: JBoss e persistenza EJB

Salve,
sto realizzando un'applicazione che utilizza alcuni EJB di tipo Entity da me
definiti. La mia perplessità nasce dal fatto che l'application server
richiama il metodo ejbStore degli EJB molto spesso, anche se accedo alle
informazioni solo con metodi getter.
Attualmente l'applicazione è piccola e in fase di sviluppo e gli accessi al
database non sono un problema ma quando diventerà operativo temo un calo
delle prestazioni.
Ho letto sul NG di Jboss un thread al rigurado e si affermava che è
necessario implementare il metodo isModified() in modo che restituisca true
solo quando sono state apportate modifiche.
Qualcuno mi può confermare questa tesi o quanto meno mi sa spiegare perchè
vi sia un accesso così frequente al db (anche con il j2EE sdk 1.3 della
Sun)?
Grazie per la vostra attenzione.
Francesco

 wrote in message
news:9ourq3$12vdd$1...@news02.it.net...


 e da tenere in conto .......
La mia risposta è ancora peggio :-P
Grazie
Francesco

 viene effettuato solo quando ritenuto necessario (dallo sviluppatore!).
Si ma isModified() e puo' darsi che sono scemo io :) e' una classe non della
j2ee "standar" almeno io non lo trovo, quindi cadi nelle features di Jboss a
scapito della portabilita'.
Non conoscendolo non so dirti come si comporta.
allora vuoi delle rispposte sulla comodita' di ejbLoad() e dei consigli lato
transazionale .... ascoltami bene:
1) ci possono essere piu client che fanno la stessa findby e quindi hanno lo
stesso identico entity bean ... ora uno di questi potrebbe modificare tutte
le variabili di classe dell'entity ... e naturalmente gli altri entity
devono avere un meccanismo per sapere che qualcuno gli ha modificato i dati
che loro vedono ..... a questo ci pensa il container che invoca il metodo
ejbLoad() di tutti gli altri entity uguali ... in effetti in quel metodo e'
bene settare un flag e prima di modificare qualcosa controllarlo cosi'
magari sai se qualcuno ha fatto danni..... mi hai capito?
Come e' difficile senza disegnini spiegare queste cose :)
2) gli entity volente o meno sono tutti cmt, cioe' la loro transazione e'
gestita dal container .... se una applicazione java chiama per esempio 5
entity fa partire minimo 5 transazioni .... a meno che all'interno di quella
applicazione java ilk programmatore non abbia definito una transazione per
esempio cosi' ....
...
UserTransaction ut =
(UserTransaction)ic.lookup("javax.transaction.UserTransaction");
ut.begin();
  chiamo entity 1;
  chiamo entity 2;
 etc etc
ut.commit();
allora in questo caso l'applicazione richiede una transazione
all'application server ... e quindi gli ejb entity se sono stati deployati
con
<trans-attribute>Required</trans-attribute> oppure
<trans-attribute>Required</trans-attribute> nell'ejb-jar.xml
allora devono rientrare nella transazione dell'applicazione java ....
quindi tutti e 5 gli entity rientrano in una unica transazione .....
Ma il problema di quanto ho scritto e' che le specifiche j2ee dicono :
 ripoto un pezzo di BLUEPRINTS della Sun
Transactions in Applets and Application Clients
The J2EE platform does not require transaction support in applets and
application clients, though like distributed transactions, a J2EE product
might choose to provide this capability for added value.
So, whether applets and application clients can directly access a
UserTransaction object depends on the capabilities provided by the
container.
To ensure portability, applets and application clients should delegate
transactional work to enterprise beans.
Quindi non ti conviene farlo anche se l'application server te lo consente
perche' perderesti in portabilita'.
Quindi la soluzione ottimale è quella di far si che l'applicazione java
richiami un session bean (vedi tu se stateful o stateless, stateless piu
performante ma ti obblica a fare commit o rollback in ogni metodo .....)
il session bean lo deploy come cmt e con un bel
<trans-attribute>RequiresNew</trans-attribute>
cosi' il session starta la transazione e se gli entity che richiama sono
deployati come ho detto prima rientrano nella sua transazione ......
ovviamente le cose a questo punto o vanno bene o vanno male ... ed il client
java o ha una buona risposta o riceve una RemoteException .....
Capito? ... che mi dici?
Se non hai database distribuiti e lavori solo su uno .... potresti fare un
bel stateless bmt settare autocommit a false, aprire una connessione fare le
tue istruzioni .... e poi fare la commit su quella connessione ....
Io ti consiglierei pure ... ma dovrei sapere i dettagli del tuo progetto
....
Spero di averti aiutato e spero di non averle sparate grosse ..... ma se
qualcuno la pensa al contrario .... vi prego ditelo ... e discutiamone ...
che sono cose veramente interessanti.
Tra l'altro tutte le cose che so .. in maniera ben ordinata tra poco le
pubblichero' su
www.javaportal.it
    .... una iniziativa della mia societa'.
Ciao a presto.


 Company Partner
Francesco

 dell'entity bean. E' giusto? E' sbagliato? Il gioco vale la candela?
il passaggio dei dati dal client al server (rappresentato dal EJB 
Session) con un oggettino serializzabile è una cosa carina...(Sempre che 
  prevedi un client Java...)
E poi dal SessionBean in poi gestisci la transazionalità del tutto (un metodo 
transazionale definito nel DD, demarchi tu una transazione con 
javax.transaction.UserTransaction)....insomma...le vie del signore sono 
infinite....o Quasi... ;)
Si, comunque è esatto...ma bisogna sempre valutare bene se inserire o no 
un framework massiccio come quello degli EJB in un progetto (ma penso 
sia OT)
Ciaooo
Giuseppe Acito
Company Slave
K-Tech S.r.l.
Via Tibullo, 13
00193 - Rome (RM) - Italy
http://www.k-tech.it
Phone: +39 (0) 6 68301467
E-mail: 
giusep...@mclink.it
AMVI 
http://www.amvi.it
ICQ 69708049
IVAO ID I-2102

Grazie a Fabrizio e a Giuseppe per la collaborazione.
Francesco