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

    come fare per bloccare il record?

    Ciao, ho una amministrazione di un sito dove accedono più amministratori.
    Spesso capita che entrambi modifichino la stessa news piuttosto che lo stesso prodotto.

    Il problema è che se utente1 e utente2 contemporaneamente aprono la pagina modifica.php?news=87 (ad esempio), entrambi vedranno il contenuto della news.
    Ognuno modifica i dati a piacimento e poi utente1 clicca su modifica. Poco dopo clicca su modifica anche utente2 "perdendo" - in quanto subito sovrascritto nel db - il lavoro fatto da utente1.

    Vorrei trovare una soluzione in modo che quando utente1 accede alla pagina modifica.php?news=87 "BLOCCHI" il record in modo che ad utente2 venga mostrato un messaggo che indica che utente1 sta modificando il record e finchè non avrà finito, lui (utente2) non potrà entrare nella pagina per modificarlo.

    SOLUZIONE:
    ho pensato: appena utente1 preme sul link che porta a modifica.php?nes=87, nel record di quella news metto il codice dell'utente 1 nel campo "utente_blocco_record". Poi quando premerà modifica, aggiornerò i campi e setterò a 0 il campo "utente_blocco_record". Fino a qua tutto bene, ma l'utente1 potrebbe entrare nella pagina bloccando il record e uscirne cliccando su qualche menu, pertanto io dovrei sbloccare il record della news non appena l'utente1 se ne va da quella pagina modifica.php?news=87 sia premendo il tasto "modifica" sia cliccando da qualsiasi altra parte piuttosto che chiudendo il browser.

    Come posso fare per intercettare questo evento e agire di conseguenza?
    con window.close() di javascript?


    Grazie
    Ciao
    www.evinformatica.it
    assistenza informatica pordenonese

  2. #2
    No, non hai nessun modo di fare questo, per una semplicissima ragione: un utente potrebbe non chiudere la finestra, ma invece lasciarla aperta senza fare ASSOLUTAMENTE NULLA, finchè la sua sessione scade: a quel punto, non hai comunque più nessun modo di riconoscere che quell'utente aveva aperto e bloccato il record in questione, quindi quel record ti resterà perennemente bloccato!

    Non è una buona idea, quindi, procedere in questo modo; la soluzione corretta è che quando salvi il record tu vada a salvare solo i campi che risultano realmente modificati da quando il record è stato mostrato a video; in questo modo, almeno, se due admin hanno modificato campi diversi, tutto procede bene.

    Se invece due diversi admin hanno modificato lo stesso campo, comunque non potresti integrare le modifiche dei due admin in una sola informazione salvata e quindi l'unica cosa sensata è che l'ultimo che salva sovrascriva la modifica fatta dal precedente...

    Il locking di un record in un ambiente come il web che è interamente basato su richieste che si aprono e chiudono nel giro del caricamento di una sola pagina non è fattibile, semplicemente.

    Ciao!
    "Le uniche cose che sbagli sono quelle che non provi a fare."
    Atipica

  3. #3
    Anch'io avevo un problema simile ed infatti ho risolto aggiungendo due campi al db, un campo l'ho chiamato "status" e l'altro è un campo data/ora.

    In pratica quando uno degli amministratori apre quel determinato record lo script scrive nel campo "status" che il record è in corso di modifica.

    Una volta terminata la modifica e salvato il record il campo "status" segnerà ancora che il record è in corso di modifica e rimane bloccato per i successivi X minuti.

    Il campo data mi serve invece per confrontare l'ultima modifica effettuata con quella in corso e se il record è stato modificato da poco tempo appare un bell'alert che avvisa che il record è stato modificato da X tempo. A quel punto l'amministratore potrà rendersi conto se qualcuno ha messo mano allo stesso record da poco tempo e decidere cosa fare.

    Alla fine è un po' quello che fa Joomla! quando un amministratore modifica un articolo. Lo blocca per un determinato tempo e non c'è possibilità di modifica da parte di altri.

  4. #4
    Che però non mi sembra una gran soluzione: se il primo amministratore passa troppo tempo a modificare quel record, che succede? Succede che lui crede di averlo ancora bloccato invece è già di nuovo libero e quando va a salvarlo il sistema gli dice picche?

    Non mi sembra per nulla ergonomico, ma forse è proprio che io non mi sento in sintonia coon Joomla!
    "Le uniche cose che sbagli sono quelle che non provi a fare."
    Atipica

  5. #5
    Certo, un timeout ci andrebbe anche.
    Beh al limite si può fare "sparire" o bloccare il tastino "modifica" quando uno dei due sta' lavorandoci e magari a salvataggio avvenuto impostare il timeout per sbloccare il tasto modifica.
    Scusate se sparlo ma data l'ora... Spero si capisca cosa voglio intendere. eheheheh

  6. #6
    ciao,
    riferendomi a quanto scritto da DigItalWarrior, vorrei sapere se è quindi corretto e doveroso fare in modo che ci sia un script in tutte le pagine che verifichi che se il record è stato bloccato es: alle 10:00:00 e ora sono le 10:10:00 (pertanto l'utente non ha cliccato su modifica - che toglierebbe il blocco- ma potrebbe aver cambiato pagina, chiuso il browser ecc) allora tolgo il blocco come se permettessi al massimo 10 min di blocco per il record. dopodichè o è salvato, oppure l'utente se n'è andato ed è rimasto appeso, quindi sblocco il record.

    potrebbe essere corretto?
    grazie
    ciao
    www.evinformatica.it
    assistenza informatica pordenonese

  7. #7

    Il silenzio è spesso la cosa migliore. Pensa ... è gratis.

  8. #8

    Re: come fare per bloccare il record?

    Originariamente inviato da verardoelvis
    Il problema è che se utente1 e utente2 contemporaneamente aprono la pagina modifica.php?news=87 (ad esempio), entrambi vedranno il contenuto della news.
    Ognuno modifica i dati a piacimento e poi utente1 clicca su modifica. Poco dopo clicca su modifica anche utente2 "perdendo" - in quanto subito sovrascritto nel db - il lavoro fatto da utente1.
    Questo problema è definito "Lost updates" e fa parte dei vari problemi che derivano dalla concorrenza sui dati (dirty reads, non repeteable reads, phantom reads).
    A differenza degli altri problemi però, questo non lo si risolve in maniera detta pessimistica con la gestione del livello di isolamento delle transazioni nel caso di tabelle innodb o con il lock table delle tabelle myisam.
    Il motivo sta nel fatto che le applicazioni web sono per natura disconnesse.
    Per risolvere il problema, bisogna gestire l'accesso ai dati in modalità cosidetta ottimistica. Il che vuol dire che l'utente1 si collega, legge e si stacca dal db. La stessa cosa fa l'utente2 e tutti gli altri che nel frattempo potrebbero collegarsi. Il primo degli utenti che finisce si ricollega e salva le modifiche nel caso nessuno sia stato più veloce di lui. L'altro utente più lento, quando si ricollega si deve poter accorgere che il record è cambiato da quando lo aveva letto e quindi l'applicazione potrebbe gestire il problema proponendo o di rinferescare la versione con quella presente nel db (store win) oppure di passare sopra a quella presente nel db (client win).

    Come si fa per accorgersi sse nel frattempo qualcuno ha modificato i dati? I modi più diffusi sono due: mettere una colonna di tipo timestamp sulla tabella che viene aggiornata automaticamente dal sistema ad ogni update; oppure tenere traccia dei valori originali del record modificato e usarli per definire il filtro di ricerca sul db, in questo modo se anche uno solo dei campi è cambiato il record non viene trovato.
    Saluti a tutti
    Riccardo

  9. #9
    E che cosa centrano le transazioni o i lock di tabella, che vengono tutti necessariamente rilasciati alla chiusura della connessione alla fine dell'esecuzione della pagina?

    Secondo me tutta questa non è una buona idea, e mi vengono in mente molti diversi scenari in cui la cosa può risultare scomodissima.

    Prima di tutto bisogna decidere se il permanere su una maschera da parte di un admin prolunga il blocco oppure no, ma entrambe le possibilità hanno dei difetti:

    1) lo prolunga, ma allora potrebbe restare bloccato per un sacco di tempo e qualche altro admin che lo vuole modificare rimarrebbe in attesa per un sacco di tempo anche se l'admin che lo ha bloccato si è semplicemente dimenticato la maschera aperta

    2) NON lo prolunga, ma allora io che l'ho bloccato devo avere modo di sapere fino a che ora l'ho reso "MIO", altrimenti potrei trovarmi che ci sto lavorando su e quello ritorna disponibile a tutti prima che io abbia finito.

    Senza contare altre potenziali difficoltà:

    1)come identifico chi ha bloccato il record e quindi è l'unico che lo può salvare e sbloccare PRIMA che scada il suo blocco? Se anche mi segnassi in sessione che "possiedo" un certo record, se per caso chiudo per errore il browser e poi rifaccio login nel pannello, non sono più il proprietario di quel record, e quindi per tot minuti quel record è bloccato e NESSUNO lo può sbloccare...

    2)Se poi hai un sistema che in un record ha più dati, di cui a gruppi si devono occupare admin/redattori diversi, vuoi perché sono in lingue diverse, vuoi perché alcuni sono dati tecnici e altri dati commerciali, comunque tu blocchi un intero record quando in realtà non ti serve...

    Insomma, non mi sembra affatto una buona idea, questa di bloccare un record in questo modo: io nel mio sistema ho implementato un blocco per redattore che fa si che un contenuto inserito da un certo redattore venga SEMPRE identificato come suo e sia modificabile solo da quel redattore o da un admin, ma non ho nessun meccanismo di blocco temporaneo del record per la modifica...
    "Le uniche cose che sbagli sono quelle che non provi a fare."
    Atipica

  10. #10
    Originariamente inviato da Shores
    E che cosa centrano le transazioni o i lock di tabella, che vengono tutti necessariamente rilasciati alla chiusura della connessione alla fine dell'esecuzione della pagina?
    Non è chiaro a chi ti stai riferendo con questa risposta. Immagino a piero.mac che ti ha suggerito un link che parla di transazioni ma sarebbe meglio quotare il testo.
    Saluti a tutti
    Riccardo

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 © 2020 vBulletin Solutions, Inc. All rights reserved.