Pagina 1 di 2 1 2 ultimoultimo
Visualizzazione dei risultati da 1 a 10 su 11
  1. #1

    [MySQL] Concorrenza in funzioni di edit - NON transazioni

    Ciao a tutti,
    devo realizzare un sito per la pubblicazione di articoli giornalistici.

    Quello che voglio ottenere è che solo un giornalista per volta possa lavorare, mediante il pannello di amministrazione, alla modifica di un articolo pubblicato.

    Nel mentre l'articolo è in fase di modifica voglio però che gli utenti del sito lo possano continuare a leggere.

    Qual'è la soluzione migliore?

    Pensavo di inserire nella tabella un campo "lock" da settare a 0 o 1 a seconda delle necessità. Questa però mi pare una soluzione sporca, anche perchè mi serve non solo sugli articoli ma anche su tutte le altre tabelle usate dal portale.

    Non esiste in mysql la possibilità di assegnare a un record un lock in edit e, specularmente, di chiedere al DBMS se quel record è lockato prima di permettere l'avvio di un'altra procedura di editing? (Ovviamente continuando a permettere operazioni di SELECT)

    Ciao e grazie!

  2. #2

  3. #3
    LOCK TABLES mi blocca tutta la tabella, non un singolo record..

    Oltretutto temo che nel momento che lo script termina la sua esucuzione il LOCK viene rilasciato..


  4. #4
    Originariamente inviato da superpelo
    LOCK TABLES mi blocca tutta la tabella, non un singolo record..

    Oltretutto temo che nel momento che lo script termina la sua esucuzione il LOCK viene rilasciato..


    il lock viene rilasciato quando si chiude la connessione o se lo chiudi esplicitamente.
    Per lavorare a livello di record ci sono le transazioni...ma visto che vuoi lavorare non su lock momentanei ma prolungati nel tempo non vedo perchè la soluzione del campo lock non ti piaccia

  5. #5
    Perchè dovrei aggiungere in ogni tabella un campo apposito.. altrimenti sto pensando che potrei creare una tabella dedicata in cui tenere traccia dei lock per non "sporcare" tutte le mie tabelle.

    Non avendo mai lavorato coi lock mi chiedevo appunto se esistesse già qualcosa che potesse fare al caso mio senza dovermelo costruire..

    Ciao e grazie!

  6. #6
    Originariamente inviato da superpelo
    Perchè dovrei aggiungere in ogni tabella un campo apposito.. altrimenti sto pensando che potrei creare una tabella dedicata in cui tenere traccia dei lock per non "sporcare" tutte le mie tabelle.

    Non avendo mai lavorato coi lock mi chiedevo appunto se esistesse già qualcosa che potesse fare al caso mio senza dovermelo costruire..

    Ciao e grazie!

    vabbè mo sporcare le tabelle aggiungendo una colonna 0,1 mi sembra un po esagerato eh

  7. #7
    Utente di HTML.it L'avatar di alpeweb
    Registrato dal
    Oct 2002
    Messaggi
    1,691
    Ricordati di considerare anche i casi in cui gli utenti "si dimenticano" di fare il logout
    o di chiudere le pseudo transazioni, oppure lo stesso account aperto da diverse sessioni.
    Potrebbe rimanerti il flag a 1 per mesi, oppure pasticci dei quali poi sarai tu il responsabile.

    In realtà credo ti convenga tenerti una tabella di log sulla quale puoi anche controllare
    i tempi di connessione e confrontarli con il timeout che desideri.

    Quindi:
    se ti fai una tabella in cui metti id_utente, id_session, time_login, time_expire, id_articolo
    risolvi i tuoi problemi semplicemente controllando l'id_articolo e
    (time_expire - timeout) > now.

    Chiaramente ad ogni operazione sullo stesso id_session vai ad incrementare il time expire
    aggiungendo il timeout.
    ...altri 5 anni di purga...

  8. #8
    Pensavo anche io a una soluzione del genere:

    LOCK(tabella,content_id,utenti_id,data);

    Dove tabella + content_id sono la chiave (e raqppresentano la risorsa lockata), utenti_id è l'utente che detiene il lock e data è il timestamp dell'istante in cui è stato acquisito il lock.

    Mettiamo che un utente possa possedere il lock per al più 1h (tempo più che sufficiente per modificare un record). Dopo questo tempo tutti i lock vengono rilasciati in automatico.

    Se un utente fa il logout tutti i suoi lock vengono rilasciati.

    Quando vengono salvate le modifiche (o annullate) i lock vengono rilasciati.

    In questo modo nessuno blocca la risorsa per sempre e tutto il sistema è agile.

    La tabella LOCK la faccio con INNODB e le query su di essa le metto in una transazione, così dovrebbe filare tutto liscio.

    Che ne dite?

  9. #9
    Originariamente inviato da superpelo
    Pensavo anche io a una soluzione del genere:

    LOCK(tabella,content_id,utenti_id,data);

    Dove tabella + content_id sono la chiave (e raqppresentano la risorsa lockata), utenti_id è l'utente che detiene il lock e data è il timestamp dell'istante in cui è stato acquisito il lock.

    Mettiamo che un utente possa possedere il lock per al più 1h (tempo più che sufficiente per modificare un record). Dopo questo tempo tutti i lock vengono rilasciati in automatico.

    Se un utente fa il logout tutti i suoi lock vengono rilasciati.

    Quando vengono salvate le modifiche (o annullate) i lock vengono rilasciati.

    In questo modo nessuno blocca la risorsa per sempre e tutto il sistema è agile.

    La tabella LOCK la faccio con INNODB e le query su di essa le metto in una transazione, così dovrebbe filare tutto liscio.

    Che ne dite?
    che è la stessa cosa fatta così o con campo lock e timestamp

  10. #10
    Utente di HTML.it L'avatar di alpeweb
    Registrato dal
    Oct 2002
    Messaggi
    1,691
    personalmente non lockerei niente e soprattutto eviterei gli automatismi inutili.
    basta crearti i dati sufficienti per sapere se qualcunaltro sta editando l'articolo in questione
    prima che sia scaduto il tempo a disposizione per le modifiche (altrimenti lo sbatti fuori),
    ed eventualmente notificare la situazione.
    ...altri 5 anni di purga...

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.