[Static vs Singleton] Java e database

di il
3 risposte

[Static vs Singleton] Java e database

Il panorama è il seguente:
molti client richiedono ad una servlet dati, il quale a sua volta li preleva da un db e risponde alla richiesta del client.

Sto cercando di capire i vantaggi e svantaggi nell'utilizzare una classe a metodi statici o un singleton per sfruttare il database ad ogni richiesta di un client.
Per ora ho capito solo che con il singleton, nel momento in cui dovessero arrivare più richieste contemporaneamente, il client del database che preleva i dati, sarebbe lo stesso. (il client db garantisce il multithreading?!?)
Mente con una classe a metodi statici per ogni client, verrebbe istanziato dalla servlet un nuovo client db.

Es: due client web richiedono un dato ad un server contemporaneamente. Col sigleton gli veberrebbe affibbiato lo stesso client db per prelevare l'informazione, quindi è una relazione molti a uno tra client web e client db in una situazione di parallelismo. Nel momento in cui un client web conclude la transazione chiudendo il client db, l'altro verrebbe appeso?
Mentre con una classe a metodi statici ad ogni client web verrebbe associato un client db.

Avete esperienze e consigli in merito?

Grazie

3 Risposte

  • Re: [Static vs Singleton] Java e database

    Facendo una prova avviando vari threads, i quali utlizzano la classe che gestisce il database progettata secondo lo Strategy, dai 100 threads in su, lancia "Exception opening socket" e "Connection refused: connect" quindi non risulta Thread Safe.
    
    public class Test {
    	
    	 Runnable r = ()->{	
    		 
    		CrucyDB c = CrucyDB.getInstance();
    		
    		c.insert("Elettronica", 0.6, "Arduino");
    		c.insert("Informatica", 0.6, "Java");
    		c.insert("Algoritmi", 1.0, "Dijkstra");
    		System.out.println(c.find("Informatica", 0.6, new ArrayList<>()));
    		System.out.println(Thread.currentThread().getName());
    		c.closeDB();		
    	};
    	
    	
    	public void genera(){
    		for(int i=0; i<100; i++){ new Thread(r,""+i).start(); }
    	}
    	
    	
    	public static void main(String[] args) {
    		Test t = new Test();
    		t.genera();
    	}
    
    }
    
  • Re: [Static vs Singleton] Java e database

    L'idea e' buonina, ma non e' il modo giusto di ragionare.

    Metodi statici: li devi pensare piu' come delle funzioni che come dei metodi veri e propri.

    Singleton: e' un oggetto di cui esiste in un'unica istanza.

    Quando serve? Ci sono casi standard che devi considerare:

    0) nel 99.9% dei casi al posto di una sfilza di metodi statici. Avere un oggetto invece che metodi statici ti permette di ragionare in termini di oggetto (appunto) che puo' essere messo in una collezione, derivato, wrappato, ...

    1) quando basta un solo oggetto per fare tutto quello che serve. In un contesto multithreading, questo vuol dire che NON PUO' AVERE STATO, quindi membri di istanza. Oppure, le modifiche allo stato sono opportunamente sincronizzate.

    Un'altro esempio e' il DATABASE NULLO: un DB virtuale che contiene QUALUNQUE TABELLA, ma TUTTE LE TABELLE SONO VUOTE.
    ...

    2) quando rappresenta un valore speciale: l'oggetto NULLO/VUOTO/NON SPECIFICATO. Ad esempio, la stringa nulla ("") puo' essere sicuramente un singleton di tipo String.
    Gli oggetti Boolean.TRUE e Boolean.FALSE sono dei singleton.

    Per quanto riguarda l'accesso al DB, stai ragionando male!
    Per sua natura un DB (almeno uno serio) puo' essere acceduto in modo concorrente.
    Quindi e' limitativo usare un singleton per la gestione della connessione (UNA SOLA): questo vorrebbe dire che due pagine non possono accedere allo stesso DB contemporaneamente.

    NON PUOI USARE LA STESSA CONNESSIONE, NELLO STESSO MOMENTO per servire due client distinti: e' disastro assicurato.

    Invece, quello che si fa, e qui' si che ha senso un singleton, e' quello di usare un POOL di connessioni.

    Il gestore del POOL e' un sigletone, perche' e' responsabile della gestione di TUTTE le connessioni richieste dall'applicazione (caso 1) della lista di cui sopra).
    Ogni volta che qualcuno richiede una connessione, la richiede al POOL.
    Se il POOL ne ha una gia' pronta, la consegna, altrimenti la crea
    Quando l'utilizzatore ha finito di usare la connessione, la chiude.
    Ma la chiusura NON E' una vera chiusura, ma la riconsegna della connesione al POOL.

    Tieni presente che la CREAZIONE di una connessione al databas e' un'operazione COSTOSA, perche' richiede l'autenticazione, e l'allocazione di risorse SIA lato client sia lato DB.
    Riusare una connessione gia' esistente, invece, non costa nulla.

    Inoltre, il POOL puo' gestire il numero minimo e massimo di connessioni, la validazione della connessione, la chiusura delle connessioni non usate piu' da un certo tempo, ...

    Il risultato e' che puoi avere N-mila client che accedono al DB, ma tutti questi N-mila cliento potrebbero usare si e no una decina di connessioni, e senza che tra di loro ci sia interferenza.

    Chi si occupa di gestire la sequenzialita' nell'accesso al database?
    IL DB STESSO, e' il suo mestiere e lo sa fare molto bene
    E' lui il singleton!

    Nota: esistono gia' librerie per la gestione del pool di connessioni.
    Ma puo' essere un bel esercizio implementarne una propria.
  • Re: [Static vs Singleton] Java e database

    Grazie mille e per quanto riguarda l'esercizio del creare un thread pool da zero, sarebbe davvero illuminante.

    Si stavo leggendo che MongoDB utilizza appunto un thread pool per la gestione delle richieste. Quindi per concludere basta e avanza un semplice oggetto da instanziare ad ogni richiesta e che faccia riferimento al db e alla collezione di documenti d'interesse.
Devi accedere o registrarti per scrivere nel forum
3 risposte