Newsgroup: it.comp.java
Titolo: Memorizzazione periodica su server remoto

Ciao a tutti,
devo realizzare un'applicazione java che trasmetta ogni 10 secondi una
tupla di 3-4 campi ad un server remoto per la memorizzazione. Pensavo
di procedere in questo modo:
- lato server remoto: dbms mysql (per archiviare i dati ricevuti dalla
trasmissione)
- lato client: applicazione java che effettua una connessione odbc al
db mysql remoto
Il carico di lavoro previsto è abbastanza elevato, infatti ci
sarebbero circa 100 clients, ognuno dei quali trasmette i dati ogni 10
secondi.
Pensate sia una buona soluzione?
Grazie
Carmelo

 Carmelo
credo dipenda molto da come intendi gestire le connessioni, dal carico 
del server remoto (come macchina intendo), dalla linea.
Secondo me come design non č sbagliato cosě in generale. Credo dipenda 
appunto dai dettagli. L'unico grosso problema che mi viene in mente č la 
gestione dei lock se usi transazioni

 gestione dei lock se usi transazioni
Credi che in questo caso sia necessario gestire dei lock?
Non saprei, perchè su questa tabella in scrittura ci sarebbe soltanto
una operazione di insert, per inserire la tupla di 3-4 campi trasmessa
da ognuno dei client. Se la insert si può considerare una operazione
atomica allora credo che forse non servirebbe gestire i lock...
Che ne pensate?

carmelo ha scritto:

Se devi fare degli insert fregandotene dell'Id generato E dell'ordine 
con cui vengono inseriti direi che sei già a posto.
Altrimenti devi andare di transazione.
Io comunque sia ti consiglierei di usare le stored-procedures: il 
comando sql viene elaborato solo una volta (la prima) e poi se ne usa la 
  versione in cache, passandole solo i parametri necessari. Questo di 
solito porta a dei buoni risultati in termini di prestazioni.
Le Stored-procedures ci sono solo dalla 5.0 in poi

 Pensate sia una buona soluzione?
se questa operazione avviene attraverso internet la boccio senza pietà.
altrimenti può andare bene, mysql con delle tabelle myisam è velocissimo 
se devi fare insert secche anche con tante connessioni simultanee.
-- 
++ Fino all'anno scorso avevo un solo difetto. Ero presuntuoso.
http://unopuntozero.wordpress.com/
http://www.flickr.com/photos/marko_po/

 db mysql remoto
Perché il server deve avere un interfaccia mysql (o jdbc) quando:
  - l'interfaccia jdbc č piů complicata di quello che ti serve
  - in futuro, o anche subito per fare i test, vorresti poter collegare 
il client ad un server che utilizza un altro backend per memorizzare i 
dati (magari un proxy).
Io fare un interfaccia RMI, SOAP, o qualsiasi altra cosa.
Ad esempio (in ASCII UML):
+------+               +------+           +--------+
|client|------(o-------|server|-----(o----|database|
+------+      RMI      +------+    JDBC   +--------+
In questo modo č molto semplice unit testare il client sostituendo il 
server con un mock.
Inoltre si potrebbe considerae di aggiungere un ulteriore strato (un 
DAO) tra server e database per semplificare il test di server.
-- 
Andrea Francia
http://andreafrancia.blogspot.com/2008/07/colinux-linux-dentro-windows.html

 se devi fare insert secche anche con tante connessioni simultanee.
L'operazione avviene attraverso una rete wireless. In pratica su un
piazzale ci saranno degli access point, attraverso il quale i clients
accederanno alla rete


Non servirebbe avere un ID, perchè ogni tupla è identificata da
(utente,timestamp)

 Andrea Franciahttp://
andreafrancia.blogspot.com/2008/07/colinux-linux-dentro-window.
..
Sarebbe forse meglio orientarsi verso i Web Services, per astrarre
lato client dal DB utilizzato?


Dovresti:
  1. astrarre il client dal tipo di database usato
  2. astrarre il server dal tipo di database utilizzato
  3. astrarre il server dal dialetto SQL usato nel database
Pero' non devi astrarre sempre tutto l'astraibile! Dipende dal tipo di 
progetto dai requisiti di riutilizzabilità dell'applicazione, dal costo 
delle modifiche e dal fatto se si vuole affrontare adesso o in futuro 
(quando effettivamente passerai da MYSQL a Oracle).
Per esempio tu potresti cominciare con il punto 1 che sicuramente è il 
piu' importante e semplifica sia il disegno dell'interfaccie e che il 
testing (mediante l'uso dei mock).
Per fare il punto 1 puoi usare i web services, ma non è l'unica scelta, 
puoi usare anche RMI, oppure CORBA o un protocollo ad hoc 
(sconsigliatissimo).
Il punto 2 lo hai già gratis con JDBC.
Il punto 3 non è sempre necessario, dipende dal progetto, comunque puoi 
implementarlo in uno dei seguenti modi:
  - usando JPA,
  - facendo un DAO,
  - facendo un DAO e usando JPA
  - altri metodi che non conosco
La scelta tra i vari metodi dipende dal tipo di progetto.



E se due utenti si collegano allo stesso secondo?


 E se due utenti si collegano allo stesso secondo?
basta mettere la tupla in chiave.


secondi.
100 client che mandano dati ogni 10 secondi non sono affatto un carico
"abbastanza elevato". Penso che la tua soluzione vada bene.

  - l'interfaccia jdbc è più complicata di quello che ti serve
Quello che deve realizzare mi sembra un sistema piuttosto semplice.
Perché vuoi fargli complicare la vita con un three-tier? Oltretutto
non c'è un vero carico di lavoro (i carichi di lavori veri sono quelli
di decine di migliaia di client che inviano dati con frequenza alta). 

lato client dal DB utilizzato?
Carmelo, non sparare alle mosche con i cannoni. Sviluppa qualcosa di
semplice e testane un prototipo. Se si rivelerà inadeguato, allora
procederai a valutare strade alternative. Purtroppo i programmatori
Java hanno l'abitudine di sovraingegnerizzare :-)

Io comunque sia ti consiglierei di usare le stored-procedures
Non sono d'accordo. Sta costruendo un sistema semplice, non
complicateglielo prima del tempo. Non ha bisogno di sp.

E se due utenti si collegano allo stesso secondo?
Quella è evidentemente la chiave. Se due utenti entrano allo stesso
secondo, avranno comunque un codice utente diverso. In ogni caso (x
Carmelo), io non consiglio di usare il timestamp nelle chiavi. Non
ricordo come li memorizza MySQL, ma questi campi sono di solito
gestiti come floating e quindi inaffidabili in quanto a precisione,
per definizione.


Perché così può unit-testare il client mock-ando il server.


Perché così può unit-testare il client mock-ando il server.
Non mi sembra che, per la sola esigenza di voler testare il client in
un certo modo, si DEBBA implementare una certa architettura. Il gioco
non vale la candela, a mio parere. Lo unit-testing, poi, si può fare
ugualmente.

 ugualmente.
Si può fare ma è piu' complicato da automatizzare e da testare.
Bisogna avere tutta questa parte di preparazione che complica le cose:
  1. Avere mysql sulla macchina di sviluppo e sul sistema di continous 
integration
  2. Attivare mysql
  3. Sapere la porta di mysql (nel caso del sistema di continous 
integration che potrebbe ospitare già un suo server mysql).
  3. Eseguire l'SQL che ricrea le tabelle (cancellando i vecchi dati)
Tu vuoi semplificare togliendo il three tier e mettendo il two tier 
pero' in realtà stai complicando in :
  - configurazione del client (dovuto all'aumento della complessità 
dell'interfaccia a cui deve collegarsi il client)
  - configurazione dei test (per lo stesso motivo)
  - automatizzazione dei test (perché è più complicato mock-are un 
server mysql che un servizio RMIo SOAP con un solo metodo).
  - il deploy del client: perché devi portarti dietro la configurazione 
del server hostname, porta, nome database, nome utente
  - la sicurezza (devi crearti un utente che può solo fare insert)
  - la validità dei dati (chi ti dice che il client scrive la data 
corrente e non si sbaglia perché la timezone non è CEST oppure che ci 
sia un client maligno che inserisce date sbagliate?)
Certo uno può usare l'approccio quick&dirty pero' prima di usarlo 
dovrebbe considerare tutte queste cose, valutarle nel caso particolare e 
poi solo alla fine decidere.


On 8 Ott, 23:49, Andrea Laforgia

sono d'accordo :-))))

 per definizione.
Cosa mi consiglieresti quindi invece del timestamp?

 Andrea Franciahttp://
andreafrancia.blogspot.com/2008/07/colinux-linux-dentro-window.
..
Grazie mille per i preziosi consigli...
In ogni caso non ci sarebbero problemi di sicurezza lato client in
questo progetto, in quanto i client sono contenuti in un pc
industriale non accessibile da utilizzatori umani (è una specie di
scatola nera di cui non ci sono diretti utilizzatori umani).

 wrote:



Cosa mi consiglieresti quindi invece del timestamp?
Per risponderti in modo intelligente dovrei prima sapere quali sono
esattamente i requisiti della tua applicazione. E' anche questo che
determina la natura delle chiavi. Che cosa sono i tuoi dati? hanno una
chiave naturale? volendo potresti creare un progressivo, ma se vuoi
impostare constraint di unicità bisogna conoscere i tuoi dati...

Certo uno può usare l'approccio quick&dirty
Non mi fraintendere: io non parlo affatto di quick & dirty. Non
consiglierei mai soluzioni "sporche". Io credo che la soluzione ideata
da carmelo sia più che pulita e sufficiente. Ho ribattuto alle inutili
complicazioni.

 complicazioni.
Le cose che ti semplificano il deploy o la sostituzione di componenti 
sono utili o inutili a seconda del progetto.
Le cose che ti semplificano il testing mi sembra difficile che siano 
inutili.


 Carmelo
Ma che idea avete del "carico di lavoro previsto è abbastanza elevato"?
Qui si parla di 10 operazioni al secondo, una cosa ridicola per 
qualunque RDBMS.
MySQL su un server scarsino (ma anche MS SQL, Firebird, Oracle, 
PostgreSQL, ecc..., forse anche Access :-) regge migliaia di insert al 
secondo su una singola connessione e centinaia di operazioni di 
connessione/insert/disconnessione al secondo.
Ciao.

On 9 Ott, 19:37, Andrea Laforgia

La chiave che identifica univocamente ciascuna tupla è (nome,
posizione, datetime)