Visualizzazione dei risultati da 1 a 10 su 10
  1. #1
    Utente di HTML.it
    Registrato dal
    Feb 2011
    Messaggi
    81

    [JSF] Connessione al database MySql

    Salve a tutti, sto studiando le JSF seguendo il libro di Deitel "Java for programmers" seconda edizione.
    Il libro lo reputo ottimo. Ma ci sono delle cose che vorrei chiedere a voi esperti. Più che altro si tratta di chiarimenti tecnici più che didattici:

    Vengo al dunque.

    Nel livro al capitolo 30 vi è lo studio dell'interfacciamento tra JSF e database. L'esempio è riportato con Java DB. Ma questo adesso non è un problema. Più che altro vorrei capire una cosa: nel libro viene usato glassfish come server e viene fatto un CONNECTION POOL relativo appunto alla connessione della pagina con JavaDB. Dopo di che viene creato un DATA SOURCE NAME per collegare agevolmente la pagina al DB.
    Infatti nel BEAN basterà richiamare la parola chiave @Resource, passando come parametro il percorso, per richiamare il DataSource.

    Io voglio utilizzare MySql nei miei progetti, e sono abituato ad connettermi al DB richiamando il driver e poi creare la connessione tramite Drivermanager:

    codice:
    Class.forName("com.mysql.jdbc.Driver");             
    Connection conn = DriverManager.getConnection("jdbc:mysql://percorso_db", "admin" , "psw");
    piuttosto che datasource.getconnession.

    1) Quale è però la soluzione migliore?

    Il connection pool lo si puo fare lo stesso su server e anche data sourcename.

    Quando sposto il processo da locale a server remoto, devo fare queste impostazioni sul server dove mi troverò ma,

    2) ci sono differenze dal punto di vista delle prestazioni?

    Altra cosa

    3) Sulla base della Vs. esperienza, meglio Java DB o MySql


    Grazie

  2. #2

    Re: [JSF] Connessione al database MySql

    Originariamente inviato da foralobo

    1) Quale è però la soluzione migliore?
    La soluzione migliore per applicativi web che hanno un numero X di utenti e quella appunto del datasource in quanto permette di avere più connessioni aperte con il database senza avere l'overhead di doverne aprire una o più di una per ogni utente della nostra applicazione. In secondo luogo permette anche di "centralizzare" la configurzione della connessione al di in unico punto.
    Il connection pool lo si puo fare lo stesso su server e anche data sourcename.
    Il connection pool e il datasource si creano sempre sull'application server.
    Quando sposto il processo da locale a server remoto, devo fare queste impostazioni sul server dove mi troverò ma,

    2) ci sono differenze dal punto di vista delle prestazioni?
    Come spiegato sopra le prestazioni cambiano e sopratutto cambia il modo di usare le connessioni al db in quanto non dovrai più preoccuparti di aprire o chiudere una connessione perché ci pensa il server a farlo per te
    Altra cosa

    3) Sulla base della Vs. esperienza, meglio Java DB o MySql
    Sicuramente il secondo. Java db è un buon database per lo sviluppo ma che personalmente non lo userei mai per gestire un applicativo serio

  3. #3
    Utente di HTML.it
    Registrato dal
    Feb 2011
    Messaggi
    81
    Posso creare un connection pool senza datasource? cioè connessione con driver e connection pool da server?

  4. #4
    Allora qui si entra in merito al server che stai usando infatti glassfish divide le due altri application server no. Per rispondere alla tua prima domanda che te ne fai di un connection poll senza avere un nome per richiamarlo?
    La seconda non lo capita, ripeto queste operazioni si compiono sul server e ovviamente le modalità di creazione variano da server a server. In glassfish si possono creare datasource sia dalla console web che da prompt di comando con asadmin

  5. #5
    Utente di HTML.it
    Registrato dal
    Feb 2011
    Messaggi
    81
    Ed all'interno di un'app web, per cosa per esempio è utile avere un database richiamato con datasource e per cosa se ne puo fare a meno?

    per esempio un menu multilingua? Altri contenuti nel footer, nel corpo etc...?

  6. #6
    Originariamente inviato da foralobo
    Ed all'interno di un'app web, per cosa per esempio è utile avere un database richiamato con datasource e per cosa se ne puo fare a meno?

    per esempio un menu multilingua? Altri contenuti nel footer, nel corpo etc...?
    Un database ti serve a gestire la persistenza dei dati e questo sia in applicativi web che non. Quindi se nel tuo applicativo hai bisogno di immagazzinare dati in maniera strutturata e che siano facilmente richiamabili la via del database è quella più ovvia.
    Nel caso particolare potresti avere una tabella che in base alla lingua ti restituisca i titoli del menù per quella lingua

  7. #7
    Utente di HTML.it
    Registrato dal
    Feb 2011
    Messaggi
    81
    ti ringrazio ma forse l'ultimo mess non era chiaro. Mi chiedevo se ci sono delle parti di un sito dove è piu utile utilizzare uno piuttosto che l'altra soluzione.
    Inoltre mi chiedevo: app come i grando social network, come vengono gestiti?

  8. #8
    Se ti riferisci se ci sono parti di un sito dove è meglio usare un datasource o una connessione diretta al db be' rivedi un po' quello che ho scritto nel primo messaggio e tutto li. Le due cose non le mischierei a prescindere anche se mi è capitato di doverlo fare ma era veramente un eccezione per cui non ne potevo fare a meno.

  9. #9
    Utente di HTML.it
    Registrato dal
    Feb 2011
    Messaggi
    81
    esatto mi riferivo proprio a quello, adesso ho le idee piu chiare.
    Per quanto riguarda i grossi social network invece?

    come vengono gestiti da questo punto di vista?

  10. #10
    Be' a parte che i più grossi social non sono open suorce e quindi non si sa esattamente come essi siano fatti. Sicuramente al loro interno avranno database SQL e NON-SQL e ovviamente faranno un largo uso di pool di connessioni con ovvie politiche di carico in modo da sfruttare le mega warehouse che hanno a loro disposizione

Permessi di invio

  • Non puoi inserire discussioni
  • Non puoi inserire repliche
  • Non puoi inserire allegati
  • Non puoi modificare i tuoi messaggi
  •  
Powered by vBulletin® Version 4.2.1
Copyright © 2025 vBulletin Solutions, Inc. All rights reserved.