Pagina 1 di 3 1 2 3 ultimoultimo
Visualizzazione dei risultati da 1 a 10 su 23
  1. #1
    Utente di HTML.it
    Registrato dal
    May 2006
    Messaggi
    378

    [JAVA] info per applicazione e db

    Ciao, sto realizzando un applicazione che legge dati da un database postgres e siccome il tizio che la vuole non ha molto le idee chiare è passato dal dirmi che voleva una sola applicazione a dirmi che ne voleva una per ogni macchina... Questo comporta problemi per la midifica dei dati, in quanto quando più utenti vogliono modificare lo stesso dato potrebbero verificarsi delle incongruenze...

    Sto quindi cercando un modo semplice e funzionle che permetta a più client di leggere e modificare dati da un db senza pregiudicarne la correttezza. In particolare mi servirebbe trovare un modo per bloccare una enupla del db quando un utente la vuole modificare per impedire agli altri di modificarla... ciò nonostante deve comunque rimanere leggibile da tutti.

    L'applicazione l'avevo cominciata utilizzando i dirver di connessione postgres ma a questo punto non va più bene...


    Qualcuno ha qualche idea ?? Ho cercato un po qua e la e l'unica soluzione sembra essere quella di scrivere un applicazione che si interfaccia al DB e da questa inviare i risultati delle query ai vari client.... A questo punti però mi sorge il problema di inviare via socket degli oggetti di tipo ResutSet... HELP PLEASE !!! :-)

  2. #2
    Moderatore di Programmazione L'avatar di LeleFT
    Registrato dal
    Jun 2003
    Messaggi
    17,320
    Il problema della concorrenza non dovrebbe essere risolto da te, ma automaticamente dal DBMS: è questo che si occupa di garantire la correttezza dei dati, l'accesso concorrente e tutto il resto.
    Io non conosco Postgres, ma se prevede l'utilizzo delle transazioni, allora non ti resta che utilizzarle.


    Ciao.
    "Perchè spendere anche solo 5 dollari per un S.O., quando posso averne uno gratis e spendere quei 5 dollari per 5 bottiglie di birra?" [Jon "maddog" Hall]
    Fatti non foste a viver come bruti, ma per seguir virtute e canoscenza

  3. #3
    Utente di HTML.it
    Registrato dal
    May 2006
    Messaggi
    378
    Ciao grazie per la risposta... però nn capisco cosa intendi per transazioni....


    Ora come ora il mio programma carica i dati relativi a un cliente e li visualizza, a questo punto uno degli utenti che lo utlizzano potrebbe voler cambiare alcuni dati. Preme il bottone modifica dati (che rende editabili i campi precedentementi caricati dal DB) e fa alcune modifiche. Il mio problema è che fra il momento in cui preme il bottone modifica e l'effettivo momento in cui preme il bottone salva qualche altro utente potrebe modificare gli stessi dati. In questo modo l'utente che salva per primo automaticamente perde le sue modifiche non appena il secondo preme salva apportando le sue di modifiche.

    Io avrei bisogno di un comando SQL se esiste per bloccare una enupla oppure come dicevo prima fare un programma che mi mette in mezzo fra DB e applicazione client.....

  4. #4
    Moderatore di Programmazione L'avatar di LeleFT
    Registrato dal
    Jun 2003
    Messaggi
    17,320
    Ho capito.
    Allora dovresti controllare la documentazione di Postgres per verificare se esiste qualche comando che effettua il lock del record (anche se, più probabilmente, sarà disponibile un comando per il lock di una tabella intera...).
    Se tale comando è disponibile (è sempre il DBMS a dover fornire tali strumenti, non l'applicazione che lo usa) allora ti dovrai documentare su come usarlo.
    Altrimenti, l'unica cosa che mi viene in mente, è quella di aggiungere una tabella al DB che si occupa di tenere traccia dei record attualmente bloccati e sarà la tua applicazione che, prima di permettere ad un utente di modificare i dati, controllerà che il record non sia presente nella tabella di lock.


    Ciao.
    "Perchè spendere anche solo 5 dollari per un S.O., quando posso averne uno gratis e spendere quei 5 dollari per 5 bottiglie di birra?" [Jon "maddog" Hall]
    Fatti non foste a viver come bruti, ma per seguir virtute e canoscenza

  5. #5
    Utente di HTML.it
    Registrato dal
    May 2006
    Messaggi
    378
    avevo già pensato a tutte e due le cose... su postgres e più in generale su SQL non ho trovato niente che permettesse di bloccare una sola enuplae. Per qunto riguarda invece la tabella che tiene traccia delle enuple aperte in modifica mi sembra un po troppo rischioso.... se per qualche motivo l'applicazione dovesse bloccarsi quella enupla resterebbe per sempre bloccata..... :-(

  6. #6
    Moderatore di Programmazione L'avatar di LeleFT
    Registrato dal
    Jun 2003
    Messaggi
    17,320
    Si possono prevedere dei meccanismi che non permettano che una ennupla venga bloccata per sempre. Ad esempio, la tabella dei lock dovrebbe contenere 3 riferimenti:
    1) Il record che viene impegnato
    2) L'utente che sta impegnando il record
    3) L'ora in cui è stato impegnato il record

    L'applicazione, per ogni scrittura, controlla prima se il record è impegnato andando a testare la tabella di lock. Se il record risulta bloccato da un utente si verifica quando è stato impegnato. Se è stato impegnato più di <tot_tempo> prima (ad esempio, più di 30 minuti prima), allora non si considera il lock, che viene sostituito con i nuovi parametri: cambia l'utente che impegna il record e l'ora, che diventa l'ora attuale.

    Ovviamente, se il record era effettivamente impegnato dall'utente (che nel frattempo si è, come si suol dire, "addormentato" su quell'operazione), quest'ultimo si vedrà respingere il tentativo di modifica non appena tenterà di inviare i nuovi dati (in pratica, si emula quello che succede con le sessioni internet, quando scadono: l'utente che si è addormentato perde le sue modifiche). Per far questo è necessario che l'applicazione effettui un doppio controllo:

    - Un primo controllo quando si richiede di effettuare una modifica (c'è già un utente che sta bloccando il record?)
    - Un secondo controllo quando le modifiche devono essere effettivamente inviate al DBMS (sono ancora io che sto bloccando il record?)

    In questo modo non accadrà mai che un record rimanga bloccato per sempre.


    Ciao.
    "Perchè spendere anche solo 5 dollari per un S.O., quando posso averne uno gratis e spendere quei 5 dollari per 5 bottiglie di birra?" [Jon "maddog" Hall]
    Fatti non foste a viver come bruti, ma per seguir virtute e canoscenza

  7. #7
    Utente di HTML.it
    Registrato dal
    May 2006
    Messaggi
    378
    grazie, ottima idea davvero, però c'è un piccolo problema.... se i vari PC su cui installo l'applicazione hanno l'ora sbagliata succede un disastro.... c'è un modo per avere un ora esatta uguale per tutti !?!?!

  8. #8
    Moderatore di Programmazione L'avatar di LeleFT
    Registrato dal
    Jun 2003
    Messaggi
    17,320
    La soluzione consiste nel prendere sempre l'ora del server su cui gira il DBMS.

    Una soluzione simile consiste nel fare in modo che l'applicazione che lo usa sia di tipo client/server: ciascuna postazione è un client che si connette ad un server che gira su di una macchina remota (non necessariamente la stessa su cui gira il DBMS). Le operazioni sul DBMS vengono tutte effettuate dal server, quindi tutte le operazioni saranno sincronizzate sulla stessa ora.


    Ciao.
    "Perchè spendere anche solo 5 dollari per un S.O., quando posso averne uno gratis e spendere quei 5 dollari per 5 bottiglie di birra?" [Jon "maddog" Hall]
    Fatti non foste a viver come bruti, ma per seguir virtute e canoscenza

  9. #9
    Utente di HTML.it
    Registrato dal
    May 2006
    Messaggi
    378
    scusa ma se faccio un applicazione client / server come faccio a inviare gli oggetti di tipo resaltset dall'applicazione che fa da server a quella che fa da client !?!?!


    Hai per caso qualche esempio ??? grazie ciao ciao

  10. #10
    Moderatore di Programmazione L'avatar di LeleFT
    Registrato dal
    Jun 2003
    Messaggi
    17,320
    Beh... il server lavora utilizzando i ResultSet. Al client verranno, eventualmente, inviati i dati attraverso qualcos'altro (ad esempio dei Vector contenenti tutti i record) e la comunicazione fra client e server avverrà sempre rispettando il protocollo previsto.

    Esempio:

    Il server interroga il DB e ottiene un ResultSet.
    Sempre il server prende il ResultSet, lo scorre e crea un Vector equivalente (contenente, ad esempio, una serie di oggetti Record, dove la classe Record sarà personalizzata da te).
    Il server invia al client il Vector appena ottenuto.
    Il client riceve il Vector e lo visualizza, estraendo tutti gli oggetti Record.
    L'utente modifica a video i vari campi e quando invia i dati il client impacchetta tutto in un altro Vector e lo rispedisce al server.
    Il server riceve il nuovo Vector, lo scorre e crea uno Statement per inviare la nuova query (di aggiurnamento) al DB.


    La comunicazione tra client e server deve essere trasparente. Ovvero, il client non deve sapere nulla del DB e dei meccanismi con cui interrogarlo o modificarlo: sono tutte peculiarità del server.


    Ciao.
    "Perchè spendere anche solo 5 dollari per un S.O., quando posso averne uno gratis e spendere quei 5 dollari per 5 bottiglie di birra?" [Jon "maddog" Hall]
    Fatti non foste a viver come bruti, ma per seguir virtute e canoscenza

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.