Se ho ragione, sembra che quello di cui stai parlando sia una forma di flusso di lavoro di check-out/modifica/check-in. Si desidera quando un utente sta modificando un record, nessun altro utente può nemmeno iniziare a modificare lo stesso record.
Questa è una forma di concorrenza pessimistica. Molti framework di accesso Web e dati supportano la (relativa) ottimistica concorrenza - ovvero, ti diranno che qualcun altro ha già modificato il record quando hai provato a salvare. Ottimista non ha alcun concetto di blocco, in realtà - si assicura che nessun altro utente abbia salvato tra il tempo di recupero e il tempo di salvataggio.
Quello che vuoi non è un requisito facile sul web, dal momento che il server non ha davvero alcun modo per applicare il check-in quando un utente interrompe una modifica (ad esempio chiudendo il browser). Non sono a conoscenza di alcun framework che gestisca questo in generale.
Fondamentalmente è necessario conservare le informazioni di verifica sul server. Un processo utente durante la modifica dovrebbe richiedere un checkout e il server lo concederebbe/negherà in base a ciò che sta verificando. Il server dovrebbe anche contenere le informazioni che la risorsa viene estratta. Quando un utente salva il server rilascia il blocco e consente un nuovo checkout quando richiesto. Il problema si presenta quando un utente interrompe la modifica - se è attraverso l'interfaccia utente, nessun problema ... basta dire al server di rilasciare il blocco.
Ma se si chiude il browser, si spegne la macchina, ecc. Si ha un blocco orfano. La maggior parte delle persone risolve questo in due modi: 1. Un timeout. Alla fine il blocco verrà rilasciato. Il lato positivo è che è abbastanza facile e affidabile. Gli svantaggi sono che il record è bloccato per un po 'in cui non è davvero in modifica. E, devi fare il tuo timeout abbastanza a lungo che se l'utente impiega davvero molto tempo per salvare non riceve un errore perché il blocco è scaduto (e devono ricominciare da capo). 2. Un battito cardiaco. L'utente ha un ping periodico sul server per dire "sì, ancora in fase di modifica". Questa è fondamentalmente l'opzione di timeout dal n. 1, ma con un timeout molto breve che può essere aggiornato su richiesta. Il vantaggio è che puoi renderlo arbitrariamente breve. Lo svantaggio è rappresentato dalla maggiore complessità e dall'uso della rete.
I token di check-in/checkout non sono molto difficili da implementare se si dispone già di un archivio persistente transato (come un DB): la parte difficile è l'integrazione nell'esperienza utente.
fonte
2010-09-17 12:28:42
Non sono sicuro di seguirmi. Stai cercando un sistema pessimistico di blocchi che impedisca all'utente di modificare qualcosa che crede sia già in corso di modifica? O stai cercando qualcosa di ottimista che permetta il montaggio multiplo ma respinge gli invii quando i dati sono cambiati? – AnthonyWJones
Lo scenario di blocco pessimistico è troppo limitante, quindi mi sto razzolando l'idea.Non voglio che gli utenti modifichino per 30 minuti solo per rifiutare le loro modifiche quando qualcun altro li ha battuti per inviare una modifica. –
Ma lo scenario di fusione ottimistico richiede un sacco di lavoro extra da parte mia, dal momento che mi servirà uno strumento che permetta al client di unire proprietà pubbliche sugli oggetti, probabilmente in modalità griglia. –