Newsgroup: it.comp.java
Titolo: Ambienti distribuiti

Ciao a tutti,
mi trovo a dover scrivere un'applicazione web che dovrà funzionare su
più server per distribuire il carico. In questo scenario quali
soluzioni sono percorribili affinché l'accesso, da parte dello strato
di business logic, ai dati sul db possa essere transazionale o meglio
che le richieste provenienti dai vari server (application server)
siano sincronizzate? Ovviamente il DB sarà posto su di un server
dedicato.
Grazie
Mr. Deckard

 ha scritto nel messaggio 
news:3f91480c-ff9c-40d5...@y21g2000hsf.googlegroups.com...

Enterprise Java Beans.
Scorpio. 



Avevo pensato anche'io a EJB, ma la domanda è se ogni application
server ha gli ejb come può essere garantita la sincronizzazione dal
momento che ognuna girerebbe su di una JVM distinta?
Grazie mille per le delucidazioni
Mr. Deckard

Mr. Deckard ha scritto:

sostanzialmente si tratta di creare un cluster, cosa che si può fare 
tranquillamente anche con tomcat senza scomodare gli application server.
per una applicazione web di norma è sufficiente applicare una semplice 
politica di bilanciamento carico sulle richieste web, cosa che si fa 
normalmente usando il mod_jk come load balancer.
le applicazioni non hanno bisogno di sapere se sono o meno 
clusterizzate, a meno che non siano sviluppate coi piedi. l'unico 
accorgimento è una riga di configurazione sul web.xml.
il load balancer in configurazione normale suddivide il carico per 
sessione, ovvero per ogni nuova sessione sceglie il nodo su cui inviarla 
e poi la indirizza sempre su quel nodo salvo che non ci sia un down. 
questo significa che l'applicazione web richiede la replica delle 
sessioni solo in caso di failure, quindi una replica di tipo lazy è più 
che sufficiente.
quanto alle tue richieste sull'accesso al db il problema non cambia di 
una virgola fra una applicazione standalone e una clusterizzata, per la 
semplice ragione che una transazione db *non* *può* sopravvivere ad una 
richiesta web. ovvero può accadere, ma è una esigenza che non può essere 
la norma. quindi, semplicemente, la tua business logic gestirà la 
transazione per richiesta e non avrà problemi.
ps: i consigli relativi ad ejb ti mandano fuori strada rispetto al tuo 
problema del load balancing. anche se, ovviamente, non sbagli se adotti 
questa tecnologia.
-- 
 Fino all'anno scorso avevo un solo difetto. Ero presuntuoso.
http://softvalley.blogspot.com
http://www.flickr.com/photos/marko_po/

 momento che ognuna girerebbe su di una JVM distinta?
Transazioni distribuite.
Cosa intendi con sincronizzazione comunque?
-- 
Andrea Francia
alias rm='trash' #use trash command instead of removing
rm -Rfv file     #put the file in the KDE trashcan
http://www.andreafrancia.it/trash


Innanzitutto grazie,
premetto che l'applicazione che andrò a realizzare sarà soggetto ad un
altissimo carico. L'applicazione girerà sotto glassfish.
Il mio dubbio è questo, a causa di mancanza di esperienza in ambito
cluster:
Io ho n server (nodi) con la stessa applicazione i quali strati di
business logic accedono al db facendo operazioni di lettura e
scrittura che devo essere transazionali. Nel senso che una richiesta
successiva alla medesima transazione deve rimanere in attesa fino a
quando la prima abbia terminato.
Non potendo "sincronizzare" le chiamate allo strato di business logic
(girando su jvm diverse) quali sono le strade che posso percorrere? E
in più, anche se utilizzassi EJB, mi troverei con uno strato EJB
dublicato su tutti i nodi con gli stessi problemi...
Mi sbaglio?
Non mi è del tutto chiaro quando mi scrivi:
"...ovvero può accadere, ma è una esigenza che non può essere la
norma. quindi, semplicemente, la tua business logic gestirà la
transazione per richiesta e non avrà problemi...."
Grazie mille
Mr. Deckard


Ciao Andrea,
come dicevo a rootkit, avendo più nodi potrei avere due richieste di
una medesima operazione su due nodi e, dunque, le due componenti
omologhe dello strato di BL efffetturare la stessa transazione...
Ma al fine che la transazione sia integra solo una per volta deve
essere eseguita... Come garantire questo? L'unica strada è usare lock
sul db?
Con EJB come dovrei fare?
Grazie infinite
Mr.Deckard

 Mi sbaglio?
no, in sostanza non ti sbagli.

 lavoro.
Ciao Rootkit,
in sostanza quello che mi stai consigliando di invocare transazioni
direttamente sull'sql delle mie classi DAO?
Grazie

Ciao,
quello che vuole dire rootkit è:
risposta breve: si
risposta lunga:
se stiamo parlando di un DB conforme alle specifiche ACID (praticamente 
tutti quelli più "famosi": Oracle, postgresql, sqlserver, ...) 
gestiscono direttamente l'accesso concorrente ai dati, quindi se tu apri 
e chiudi la transazione ad ogni richiesta web non hai alcun problema.
Per apri e chiudi transazione ad ogni richiesta si intende:
apro connessione
...
faccio qualcosa su db
...
commit <-- chiude la transazione
Es. di 2 richieste in parallelo:
Richiesta A e richiesta B
A -> apro connessione
B -> apro connessione
A -> insert into movimenti (importo, utente) values (128, 'nolli');
B -> select max(importo) from movimenti;
A -> fa altre 50 operazioni che impiegano 1 ora ad essere eseguite
A -> commit
B -> ottiene il risultato della select solo DOPO il commit di A
B -> commit
Spero di esserti stato di aiuto.
Ciao,
Tommaso
P.S.: se rootkit non voleva dire ciò che ho scritto mi correggerà ;)
Mr. Deckard ha scritto:



Grazie Tommaso,
sei stato certamente di aiuto...
Il mio DB di riferimento in questo momento è MySQL 5...
Per capirsi, in MySQL devo esplicitamente dichiarare una transazione?
Credo che dovrei effetturare:
START TRANSACTION
 SELECT * FROM ... WHERE ... FOR UPDATE
 UPDATE
COMMIT; (TERMINE TRANSACTION)
La cluasola FOR UPDATE dovrebbe impedire alle altre richieste di
leggere i record coinvolti dalla mia transazione fino al commit,
giusto?
Grazie infinite
Mr. Deckard

E' da parecchi anni che non uso mysql; ho optato per postgresql in 
quanto, a suo tempo, più conforme alle specifiche ACID ma credo che 
ormai anche mysql sia un ottimo db.
Non so che tipo di infrastruttura / framework tu stia usando quindi ti 
scrivo come se tu usassi direttamente jdbc (no EJB, no Springframework, 
no JPA, no Hibernate, ecc.)
Connection cnn = .... // ottengo una connessione
try
{
   // autocommit deve essere false per garantire che
   // il db utilizzi una transazione unica
   cnn.setAutocommit(false);
   PreparedStatement pst = cnn.prepareStatement....
   pst.setString...
   pst.executeUpdate(); <-
   cnn.commit();
}
finally
{
   cnn.close();
}
Ovviamente il codice precedente non è testato e manca una corretta 
gestione degli errori e di eventuali rollback
Ciao,
Tommaso
Mr. Deckard ha scritto:


 Ovviamente il codice precedente non č testato e manca una corretta 


 > Tommaso
Ciao Tommaso,
in primo luogo ti ringrazio molto per la tua disponibilità... sono un
po' perplesso:
Ho scritto questo codice di prova... In pratica due thread uno inizia
la transazione e l'altro tenta di leggere mentre è in corso la
transazione:
Thread che inizia la transazione:
public class ExecuteTransaction implements Runnable{
    /** Creates a new instance of ExecuteTransaction */
    public ExecuteTransaction() {
    }
    public void run() {
        StringBuilder sql = new StringBuilder(0);
        Connection conn;
        try {
            sql.append("UPDATE session SET sessionid = 'csdcsdsd'
WHERE id = 1");
            Class.forName("com.mysql.jdbc.Driver");
            conn = DriverManager.getConnection("jdbc:mysql://localhost:
3306/persistenza", "root","root");
            conn.setAutoCommit(false);
            Statement stm = conn.createStatement();
            System.out.println("Sto per eseguire...");
            stm.executeUpdate(sql.toString());
            System.out.println("Inizio attesa: ");
            Thread.sleep(10000);
            System.out.println("Finisco attesa");
            conn.commit();
        } catch (SQLException ex) {
            ex.printStackTrace();
        }
        catch (ClassNotFoundException ex) {
            ex.printStackTrace();
        }
        catch(InterruptedException ex){
            ex.printStackTrace();
        }
        finally{
            try {
                conn.close();
            } catch (SQLException ex) {
                ex.printStackTrace();
            }
        }
    }
}
Thread che tenta di leggere un record coinvolto nella transazione:
public class ReadRecord implements Runnable{
    /** Creates a new instance of ReadRecord */
    public ReadRecord() {
    }
    public void run() {
        StringBuilder sql = new StringBuilder(0);
        Connection conn;
        try {
            sql.append("SELECT * FROM session WHERE id = 1");
            Class.forName("com.mysql.jdbc.Driver");
             conn = DriverManager.getConnection("jdbc:mysql://
localhost:3306/persistenza", "root","root");
            Statement stm = conn.createStatement();
            ResultSet rs = stm.executeQuery(sql.toString());
            while(rs.next()){
                System.out.println("ReadRecord: " +
rs.getString("sessionid"));
            }
            conn.close();
        } catch (SQLException ex) {
            ex.printStackTrace();
        }
        catch (ClassNotFoundException ex) {
            ex.printStackTrace();
        }
        finally{
            try {
                conn.close();
            } catch (SQLException ex) {
                ex.printStackTrace();
            }
        }
    }
}
Faccio partire prima il thread che crea la transazione e lo metto in
attesa per dieci secondi...
A distanza di 3 secondi lancio il thread che legge e basta...
L'output è questo:
Sto per eseguire...
Inizio attesa:
ReadRecord: sfdfsdf
Finisco attesa
Come vedi il thread ReadRecord è riuscito a leggere prima che la
transazione fosse conclusa...
:-(
Grazie ancora...
Mr. Deckard

 transazione fosse conclusa...
ma questo è giusto!
durante la transazione non è impedito l'accesso in lettura alle righe 
interessate dalla transazione. solo che tu leggi ancora lo stato 
precedente alle modifiche non ancora committate. questo è l'isolamento 
della transazione.
se vuoi che il secondo thread si "accodi" in attesa, devi aggiungere la 
clausola "FOR UPDATE" in coda alla select. in quel caso dichiari di 
voler iniziare una transazione (che anche in quel caso va chiusa con 
commit o rollback) e quindi di voler leggere il dato consolidato.


B -> commit
Se stai facendo una select, non c'č nulla da "committare".

ma questo č giusto!
Il nostro amico č stato fuorviato da quanto detto da Tommaso, che non
č corretto.


Ciao Rootkit,
si nel frattempo avevo provato ad aggiungere FOR UPDATE (come avevo
ipotizzato in qualche messaggio fa) e in effetti funziona!!!
Ma in generale non dovrebbe essere chi inizia la transazione (il primo
thread) a dire che ha inizio una transazione che inibisce la lettura
agli altri?
Ad esempio se il mio primo thread deve fare una select per leggere un
valore e poi modificarlo è sufficiente mettere for update in questa
select per impedire che gli altri thread leggano quel record o anche
le query (select) degli altri thread devo avere l'indicazione for
update?
Vi ringrazio tutti....
Mr. Deckard.

 Se stai facendo una select, non c'è nulla da "committare".

agli altri?
In generale, le transazioni non inibiscono le letture. Transazioni
concorrenti non sono necessariamente serializzate (guai se fosse
così!). Le transazioni possono avere livelli di isolamento differenti
(vedi lo standard SQL). Tieni presente che il "for update" non è una
caratteristica standard e potrebbe essere implementata o meno, a
seconda del db.

 update?
la FOR UPDATE si usa nel momento in cui vuoi che il dato letto non sia 
modificato da altri. l'esempio tipico è il numeratore: se hai una riga 
di tabella che fa da numeratore, tu devi leggere il dato, incrementarlo 
di uno e riscriverlo, se vuoi rendere atomica questa sequenza (cioè non 
vuoi che qualcuno si inserisca fra lettura e scrittura a cambiarti il 
dato) usi la FOR UPDATE.
-- 


On 2 Mag, 19:01, Andrea Laforgia

Grazie Andrea,
quindi mi stai dicendo che è il thread che legge che deve
"preoccuparsi" di mettersi in coda, qualora ci sia una transazione in
corso su quei record, dichirando la clausola FOR UPDATE?
Mi rendo conto che la clusola FOR UPDATE non è standard, ma l'accesso
ai dati è effettuato attraverso delle classi DAO e quindi il variare
del db dovrebbe essere abbastanza trasparente...
Che ne pensi?
Grazie
Mr. Deckard

quando saranno consolidate.
In realtà questo è il livello di isolamento più comune (e sensato),
ovvero il read committed. Nulla vieta, però, di impostare altri
livelli di isolamento (esistono, per esempio, anche le dirty read).

Che ne pensi?
Penso che devi comunque preoccuparti del comportamento della tua
applicazione. Se la "for update" non è supportata, non è supportata.

 applicazione. Se la "for update" non è supportata, non è supportata.
Beh io intendevo che qualora il DB non sia MySQL l'applicazione
istanziera la classe DAO che provvederà a far partire la gestione
delle transazioni in modo compatibile a quel db...  Giusto?
Mr. Deckard

 
Se non sbaglio c'e' un altro approccio di semantica differente ma piu' 
performante e valido specialmente in ambienti interattivi (vedi 
applicazione web con maschere di input).
Si tratta del locking ottimistico implementato tramite colonne di 
versione (semplici timestamp o contatori) dove quando vai salvare 
controlli che il dato non sia stato modificato nel frattempo.
Se lo e', allora intraprendi qualche operazione (messaggio di 
warning/errore o sovrascrittura del dato).
In sostanza
-T1 read A
-T2 update A (causa A.vers++)
-T2 update A
L'ultima operazione (se lo vuoi) fallisce perche' A.vers <> dal 
timestamp presente nel database (del record corrispondente ovviamente).
Hibernate lo implementa automaticamente volendo.

versione
In realtà è possibile fare la stessa cosa implementando una where su
tutti i campi originali. DataSnap di Delphi consente, ad esempio, di
impedire totalmente le modifiche o consentire solo quelle per i campi
non modificati da altri.

Andrea Laforgia ha scritto:

Dalla documentazione mi risulta anche l'Hibernate con
optimistic-locking="all|dirty"
ma mi pare si possa fare solo in alcuni casi.
Comunque mi sembra piu' pulito e performante un campo predisposto a 
quello scopo. L'altra mi sembra essere una soluzione valida per database 
pre-esistenti e non modificabili.

pre-esistenti e non modificabili.
Modificare un database per aggiungere colonne di versione mi sembra
decisamente invasivo. Il metodo usato da DataSnap è sufficientemente
pulito e, da quanto vedo, funziona bene. Viene usato per tutti i tipi
di database.

 pre-esistenti e non modificabili.
io comunque con l'esempio del numeratore avevo contemplato un caso ben 
diverso, non quello della concorrenza sull'aggiornamento dei dati 
durante l'interattività utente. questo va precisato.


 questa tecnologia.
Beh, gli EJB dovrebbero garantire una buona scalabilitą anche su un singolo 
nodo, che naturalmente non significa
load balancing.
Ho letto la discussione, e suggerirei a Mr Deckard almeno una valutazione 
anche sulla macchina che fungerą da DB Server... non pensate che possa 
diventare il vero collo di bottiglia ?
Scorpio. 

 di database.
Pero' tieni presente che usando un timestamp si ha anche un buon 
significato di business: il timestamp dell'ultimo aggiornamento.
Comunque se Deckard volesse implementare questa tecnica penso che 
sarebbe molto complicato per lui una where su tutti i campi, piu' che un 
timestamp.
Cmq si, e' piu' pulito senza campo di versione.

 durante l'interattività utente. questo va precisato.
Si ma non mi riferivo all'esempio, ma piuttosto alla discussione.

 Scorpio.
Beh rinrazio veramente tutti per questo bel thread, siente andati ben
oltre le mie aspettative...
Beh il DB sarà un cluster MySQL...
Alla fine i miei casi sono i seguenti:
Lo stato di un mio ben preciso record può essere tentato
contemporaneamente da più punti dell'applicazione.
Nel particolare se lo stato è V metti a E e fai qualcosa...
Quindi vorrei che solo uno posso leggere V, passare a E e fare
qualcosa...
Dalle discussioni mi sembra di aver capito che è sufficiente impostare
la transazione come READ_COMMITTED in modo che non possono essere
letti i record finché non "committati" dalla transazione corrente?
Quindi una select successiva a una transazione su un determinato
record è bloccante?
Non mi è ancora chiara la differenza con FOR UPDATE.
Vi ringrazio tutti
Mr. Deckard


Credo di aver sbagliato nel mio ultimo post...
Nel mio caso dovrei usare READ_UNCOMITTED...
In modo che una delle richieste concorrenti veda la modifica...
Tuttavia siccorme potrei avere un medesimo update fatto su di un
medesimo record non è corretto usare la FOR UPDATE?
Scusate se sto facendo un po' di confusione...
Mr. Deckard

 
L'esempio precendente con il FOR UPDATE:
1. T1.begin
2. T2.begin
3. T1.selectForUpdate(A)
4. T2.select(A)  -> bloccata! perche' T1 ha fatto una select for update
5. T1.update(A, "pippo")
6. T1.commit     -> questo sblocca T2
7. T2.select(A)  -> ora legge "pippo"
In sostanza una SELECT ... FOR UPDATe e' una select ma dal punto di 
vista dei lock viene trattata come le operazioni UPDATE, INSERT, DELETE.
(spero che la simbologia/terminologia che ho adottato ti siano chiare).


Grazio Cicap,
sei stato molto chiaro...
mi sembra di capire che ogni operazione di lettura che poi determinano
una aggiornamento presuppongano l'utilizzo di FOR UPDATE...
Non mi è chiara l'utilità di un isolamento di tipo READ_COMMITTED...
mentre posso capire un READ_UNCOMMITTED in quando potrebbe far
decadere una condizione di update a una transazione concorrente...
Puoi aiutarmi meglio?
"FOR UPDATE" è una forma di isolamento? E allora quando utilizzare
READ_COMMITTED, READ_UNCOMMITTED piuttosto che FOR UPDATE?
Cosa intendi con quando dici
"...FOR UPDATe e' una select ma dal punto di vista dei lock viene
trattata come le operazioni UPDATE, INSERT, DELETE..."
Grazie mille,
Mr. Deckard

"FOR UPDATE" è una forma di isolamento?
Ni. Con una SELECT ... FOR UPDATE ti ... riservi il diritto di modificare il 
record letto, è un modo di dichiarare al database che il record X può essere 
modificato durante la transazione.
Di conseguenza, altre transazioni possono venire "bloccate" quando 
incontrano quel record se il loro livello è READ_COMMITTED, in quanto 
attendono di poter leggere la versione "ufficiale" del record, mentre le 
READ_UNCOMMITTED andrebbero avanti tranquillamente, perchè come ho scritto 
prima si riferiscono allo snapshot "del momento" del tuo database.
Personalmente utilizzo READ_UNCOMMITTED quasi sempre, laddove mi serve 
fornire riepiloghi in cui la certezza del dato non è molto importante ma 
basta uno "sguardo d'insieme": pensa all'elenco di utenti collegati ad un 
applicativo web in un certo istante....
Scorpio.

 affidabile, del tuo db.
Soprattutto quello stato potrebbe essere inconsistente. Ad esempio:
-Pippo ha 1000 euro in banca
-Caio ha 2000 euro in banca.
La banca apre una transazione (T1) e passa 500 euro da Pippo a Caio. Nel 
frattempo c'e' un'altra transazione che legge i 2 conti (T2):
1. T1.begin
2. T2.begin
3. T1.update("pippo", -500)
4. T2.select("pippo") --> 500
5. T2.select("caio") -> 1000.
Sono spariti 500 euro! Ovvero il conto di Caio + quello di Pippo = 1500.
6. T1.update("caio", +500)
7. T2.select("caio");   -> 500
8. T2.select("pippo");  -> 1500
Sono riapparsi i 500 euro mancanti!
Capisci che sei hai READ_UNCOMMITTED nel punto 5 ti trovi in una 
situazione che potrebbe essere inconsistente.
Invece se avessi avuto READ_COMMITTED allora la somma del conto di pippo 
e caio era sempre 2000 (perche' l'operazione 4 avrebbe ritornato 1000 e 
non 500).
Chiaramente devi valutare tu se una situazione del genere e' accettabile 
o meno.
Secondo me *generalmente* e' meglio tagliare la testa al toro e leggere 
solo i dati committati. READ_COMMITTED e' solitamente la scelta sensata 
dal momento che e' spesso sensato utilizzare le transazioni per 
raggruppare le operazioni in maniera da portare il database da uno stato 
ad un altro, in maniera atomica.
Certo puoi fare anche diversamente ma devi valutare attentamente se ne 
vale la pena o meno.

 altissimo carico. L'applicazione girerà sotto glassfish.
Ciao,
lo so, forse andava chiesto un po' prima, ma sono curioso, e credo che 
sia comunque necessario saperlo per dare una risposta sensata.
"altissimo carico"...significa?
Lucio
-- 
Lucio Benfante
JUG Padova           
http://www.parancoe.org
 ...have a look at it!
www.jugpadova.it
 
http://www.jugevents.org


Migliati di utenti,
ma dove il carico richiesto al DB potrà essere veramente notevole...
Un saluto
Mr. Deckard

 ma dove il carico richiesto al DB potrà essere veramente notevole...
E finora mi pare che non te ne sei preoccupato. Nel thread si è parlato 
di carico dell'applicazione, non del DB. Anche in questo caso ti serve 
una stima di quante richieste al secondo (query/update) e magari anche 
di quanti dati verrano estratti dal DB in ogni richiesta. Questo 
dimensionare la macchina su cui verrà ospitato il DBMS, per decidere se 
te ne serve più di uno, o per decidere di far svolgere alcune operazioni 
direttamente al DBMS, senza trasferire i dati all'applicazione.
Senza tutto questo, preoccuparsi dell'architettura dell'applicazione è 
pura dialettica.
Lucio
-- 
Lucio Benfante


 JUG Padova          
http://www.parancoe.org.
..have a look at it!
www.jugpadova.it
   
http://www.jugevents.org
Ciao Lucio,
hai perfettamente ragione. L'applicazione di cui stiamo parlando non è
un sito internet, ma una vera e propria applicazione per operatori.
Per sua natura dunque avrà una discreta interazione con la base dati.
Purtroppo in questo momento non ho stime puntualissime. Ma quale
potrebbe essere la soluzione alternativa a far svolgere i compiti
transazionali al DB?
Senza dubbio le tue considerazioni sono imprescindibili.
Ti ringrazio molto,
Mr. Deckard

 transazionali al DB?
...direi che è il caso di leggere un po' di documentazione di base:
http://java.sun.com/javaee/5/docs/tutorial/doc/bncih.html
Ripeto che comunque sarebbe il caso di fare un po' di valutazioni sugli 
effettivi requisiti dell'applicazione: è inutile costruire un razzo che 
può andare su Marte (con i relativi costi e, soprattutto, difficoltà), 
quando volerà solo nel giardinetto dietro casa.
Ciao
   Lucio
-- 
Lucio Benfante


 JUG Padova          
http://www.parancoe.org.
..have a look at it!
www.jugpadova.it
   
http://www.jugevents.org
Ciao Lucio,
ribadisco che l'applicazione sarà soggetta ad alto carico, o meglio è
un'applicazione che il requisito di scalabilità dovrà essere
soddisfatto, in quanto impossibile definire con precisione il carico a
priori. In alcuni contesti potrà avere un carico "non preoccupante",
in altri potrebbe essere molto alto. Tutto ciò è legato al fatto in
quale contesto si troverà a funzionare l'applicazione.
Ho letto il link che tu mi hai proposto,  e si torna sulle EJB e
quindi all'inizio del mio thread. So cosa siano e l'ho già usate in
passato, tuttavia non ho una grande esperienza sulle ejb, direi
ridotta. E il mio problema, che non sembra venga affrontato dal link,
cosa succede se ho n server con lo strato ejb installati su tutti e n
server. La sensazione è che le transazione, l'isolamento di esse vada
a farsi benedire... Mi sbaglio?
Per me è questo il punto fondamentale, dovuta alla mia scarsa cultura
sulle ejb.
Grazie infinite.
Mr. Deckard

 JUG Padova          
http://www.parancoe.org.
..have a look at it!
www.jugpadova.it
   
http://www.jugevents.org
Ciao Lucio,


 sulle ejb.
Sì, ti sbagli...sicuro di aver letto tutto?
http://java.sun.com/javaee/5/docs/tutorial/doc/bncjd.html
...comunque è impossibile indicare una soluzione al tuo problema di 
"carico", senza avere un'idea di cos'è che può essere sovraccaricato, e 
quanto. La risposta "tutto" è una non risposta.
Personalmente trovo che gli EJB non siano una soluzione a problemi di 
carico.
Lucio
-- 
Lucio Benfante


 JUG Padova          
http://www.parancoe.org.
..have a look at it!
www.jugpadova.it
   
http://www.jugevents.org
Ciao Lucio,
mi rendo conto di aver scritto in modo molto sintetico e di fretta...
Non intendevo assolutamente dire che le mie preoccupazioni di carico
vertono su tutto. Allora la mia grossa preoccupazione è il DB.
Per questo motivo, avevo iniziato il thread cercando pareri se
sfruttare la transazionalità e possibilità di lock  offerti dal DB
(pagandone il peso) o scegliere altre vie.
L'altra ipotesi era sfruttare le caratteristiche offerte dai container
EJB alle transazioni ecc... ma data la mia scarsa esperienza con EJB
mi ponevo il problema di come potessi garantire le transazioni...
Probabilmente mettendo lo strato in cluster? Quindi da una parte il
mio evenutale "cluster" per l'applicazione e dall'altra il cluster
EJB?
Ma questa soluzione potrebbe essere onerosa per taluni clienti e
volevo capire quali potevano essere secondo voi le strade
percorribili...
Io attualmente mi stavo orientando sfruttando il motore del DB
(transazionalità, lock, ecc...) sapendo però che avrò del prezzo da
pagare sulle performance complessive del DB (anche se esso sarà un
cluster).
Scusami se mi sono espresso e continuo a esprimermi di fretta.
Ma vi ringrazio per le vostre considerazioni e opinioni.
Mr. Deckard
P.S: adesso vado a rileggermi meglio il link...

 JUG Padova          
http://www.parancoe.org.
..have a look at it!
www.jugpadova.it
   
http://www.jugevents.org
Ciao Lucio,


 JUG Padova          
http://www.parancoe.org.
..have a look at it!
www.jugpadova.it
   
http://www.jugevents.org
Ciao Lucio,


Scusate ragazzi se mi intrometto in questa interessante discussione: secondo 
voi , dato un unico server, con tempo medio di risposta di X secondi, quante 
transazioni al secondo può reggere un application server ?
In effetti ho sempre sentito dire che "Java scala molto bene", e per 
esperienza posso dire che mi trovo d'accordo... però, se parliamo di 
numeri.....non saprei che dire.
Scorpio.