Newsgroup: it.comp.www.asp
Titolo: stesso record ?? (leggimi Liga97 !!)

Cosa succede in un applicazione sviluppata sfruttando le tecniche ASP se
piu' utenti provano a lavorare sullo stesso record di un database ?
Esiste un modo per bloccarlo ?
Come capisce l'utente che quel record è in uso da un altro utente ?
Cosa si intende per file global.asp o global.asa ?
Grazie 1000
max
pac...@netics.net

Cosa si intende per file global.asp o global.asa ?
Gloabl.asa (il global.asp non esiste) viene eseguito ogni volta (solo
una volta quando parte la sessione el'applicazione) ci puoi mettere
routine o variabili che desideri mantenere per la durata
dell'applicazione o della sessione
Ciao
Liga97
E-Mail: 
lig...@alo.it
ICQ: 11362849


e come si fa ???
grazie 1000, max
pac...@netics.net


Moderatore di it.comp.www.asp
Gruppo di supporto: 
http://www.ipoint2000.net/aspoint/
^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^
Scopri il web: servizi, spazio gratis, forum su 
http://www.ipoint2000.net
Realizzazione di ASP e Web Design su 
http://www.alpha.it/bokdan

 Come capisce l'utente che quel record è in uso da un altro utente ?
Direi di no.
La questione e' che http e' un protocollo che riapre la connessione ad
ogni richiesta (oddio, volendo si puo' settare il "HTTP Keep Alives
enabled" ma non cambia nulla per quello che voglio dire io). Al limite
tu puoi "attaccare il cavo", connetterti e scaricarti una pagina html e
poi tagliare il cavo. La pagina continui a vederla benissimo. Poi
riattacchi il cavo e vai in un'altra pagina. E poi lo ritagli e via
cosi'. Funionerebbe benissimo ;-)))
Ora, bloccare cioe' fare il lock di un record senza una connessione fra
server e client e' qualcosa di abbastanza complesso e per quel che ne so
IIS + accessori vari non hanno questa possibilita'.
Io ho trovato un modo abbastanza rozzo, ma funzionante. Ti dico subito
che c'e' un overhead non idifferente, soprattutto di rottura di c....
Abbiamo una tabella (table1) con ID (primary key) e Info (dati el
record). A questi due campi ne aggiungo altri due: lock (0/1) e IDS
(long). Il campo lock indica se il record e' bloccato e IDS riporta il
SessionID dell'utente che lo ha bloccato.
In base a che cosa vuole fare l'utente, il server dovra' fare una serie
di cose.
Se ad esempio l'utente vuole editare un record, il server dovra'
controllare che non sia bloccato, poi bloccarlo e poi mandare i dati
correnti al client. A questo punto il client edita e poi rimanda
indietro al server i dati. Il server prende i dati, li salva e sblocca
il record.
C'e' adesso da considerare i timeout. Se un utente muore davanti al
monitor ?!?!?!  :-)))  Oh, beh, basta che cada la connessione e dal
punto di vista del server non cambia nulla....
Che si fa?!??!?  Bisogna mettere in global.asa Session_OnEnd un update
Sql che sblocchi tutto cio' che l'utente ha bloccato.
E se cade il server??!?!  Altro bel casino.... In global.asa
Application_OnStart si deve sbloccare con un update sql tutti i record
bloccati. Sottolineo tutti.
Ma non e' finita: e se il client si abbiocca davanti al monitor mentre
sta editando e poi si risveglia dopo due ore e manda i nuovi dati???
Ovviamente la sua Session e' gia finita da un pezzo e quindi il suo
record non e' piu' bloccato. Quindi servono altri controlli prima di
fare l'update sul server.
Ecc. Ecc. Ecc. Ecc. Ecc. Ecc. Ecc. Ecc. 
Morale: alla fine dei conti..... non ne vale la pena! Quindi se uno ha
bisogno di accedere in modo concorrente ai dati va in rete locale con
software adatti e non con asp.  :-)))
   saluti
P.S. se vuoi il codice dimmelo, te lo mando. Comuque sappi che e' solo
una bozza e manca la parte del global.asa
---------------------------------------------
 Fabrizio Accatino
 Web:   
http://www.cclinf.polito.it/~fhtino
 EMail: 
fht...@cclinf.polito.it
---------------------------------------------

software adatti e non con asp.  :-)))
mica tanto...
estratto dalla documentazione ufficiale MS, che non mi stancherò mai di
consigliare di leggere almeno una ventina di volte... ci trovo ancora oggi
cose che neanche mi immaginavo si potessero fare...
----
rs.LockType
adLockPessimistic Pessimistic locking, record by record — the provider does
what is necessary to ensure successful editing of the records, usually by
locking records at the data source immediately upon editing.
----
che corrisponde come valore a 2.
Ne è consigliato l'uso specie in applicazioni critiche, tipo rotazione di
banners, perchè blocca i campi e ne impedisce la modifica concorrente...
in pratica, senza bisogno di fare tutto quel casino, si riesce ad avere lo
stesso un risultato accettabile...


 stesso un risultato accettabile...
Ah si ?!?!?
Facciamo un esempietto, cosi' ci capiamo.
1 - A richiede una pagina asp 
2 - il server gli manda la pagina con all'interno dei dai (in un form)
3 - A modifica i dati e spedisce indietro il form verso il server
4 - il server riceve il form e modifica il record corrispondente nel db 
    con i nuovi dati forniti dal signor A
Ora, per quel che ne so io, adLockPessimistic non permette di bloccare
il record nel periodo fra l'operazione 2 la 4. (Ti faccio notare, tra
l'altro, che tale tempo puo' essere anche relativamente lungo: anche 5 o
piu' minuti).
Che mi dici?
  saluti


Nel post ho trovato un tono sarcastico/polemico. Posso anche essermi
sbagliato, lo ammetto.
Inviterei a mantenere le considerazioni piu' tranquille.
Saluti.
Stefano.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Moderatore di it.comp.www.asp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

il record nel periodo fra l'operazione 2 la 4. (Ti faccio notare, tra
scusa, ma a che serve lockare il record gia' da 2? secondo me e' un
grosso errore, anche perche' se al passo 2 locki il record e poi
l'utente se ne va, il record rimane bloccato e devi aspettare la fine
della sessione per accorgertene... e comunque basta bloccarlo al
momento della scrittura, cioe' al punto 4. potresti dirmi che se fra
il punto 2 e il punto 4 un'altro utente modifica il record, il mio
utente vede dei dati non congruenti col contenuto del database, ma che
importa, se lui li vuole modificare puo' farlo, se gli stanno bene
cosi' ok, c'era solo un'altro utente che aveva bisogno di cambiarli :)
secondo me e' molto importante mantenere l'atomicita' delle operazioni
all'interno della singola richiesta/risposta client/server, anche
perche' non sai mai cosa puo' succedere dopo, utenti che scappano,
linee che cadono, ecc... quindi non lasciare record lockati,
connessioni a database aperte, ecc...
 - Federico Feroldi -
| 
e.mai...@pixzone.com
.
| 
http://www.pixzone.com/
| Logicom srl - Numerica srl

 connessioni a database aperte, ecc...
Vedi sopra.


cosi' ok, c'era solo un'altro utente che aveva bisogno di cambiarli :)
Potrebbe essere che aggiorni i dati "tornando indietro". Faccio un esempio
banale:
Il record contiene l'ora corrente. Sul record c'e' 15.25
L'utente A aggiorna l'ora alle 15.28 ma prima di fare l'aggiornamento
l'utente B fa l'aggiornamento alle 15.30 e cosi' quando l'utente A fa
l'aggiornamento in realta' e' una regressione.
Al contrario si puo' impostare un sistema un' po' macchinoso ma funzionale.
Si fa un update con WHERE con tutti i dati che erano stati prelevati ed
inseriti nella form.
Si fa un select con WHERE con tutti i dati appena inseriti. Se c'e' allora
si dice all'utente che l'aggiornamento e' stato effettuato, se non c'e' si
ricarica la form iniziale e si dice all'utente che nel frattempo e' stato
operato un aggiornamento al record.
Il rischio che uno si trovi sempre la form senza mai riuscire a fare
aggiornamenti cresce con il crescere del gap fra richiesta e scrittura dei
dati e con il numero di utenti connnessi al sito.


 operato un aggiornamento al record.
Ok, ma cosi' non implemento un sistema di "locking" ma un sistema di
"warning": il server si limita ad informare l'utente che qualcuno gli ha
cambiato i dati "sotto il naso". Non e' pero' in grado di bloccare il
record.
Se ho capito bene....


Che mi dici?
che quello di cui parli tu è irrilevante.
ti spiego: se io ho bisogno che più persone cambino i dati in un database,
di certo non permetto che cambino radicalmente il contenuto di un record.
Detto questo, adLockPessimistic si assicura che l'utente che modifica il
database appia accesso _esclusivo_ a quel record, in quel momento, bloccando
le richieste di altri utenti.
Poi, come la vedo io, il resto sta nella bravura di chi realizza questo
sistema.
Mi spiego: come la vedo io, non permetterò mai a nessuno di modificare
*radicalmente* il contenuto di un campo di un database, anche perchè non ne
vedo l'utilità.
Se si tratta di qualcosa che serve solo per quell'utente, faccio in modo che
abbia un suo insieme di record personali, in modo che cambi solo le cose che
gli interessano, senza rompere gli altri.
Se invece mi serve cambiare cose per tutti, cerco di farlo sempre pensando
che sono IO a dovermi preoccupare di non permettere a più utenti di cambiare
come vogliono quel dato, ma ti ripeto, per questo caso mi sembra poco utile
l'uso di un database...
A parte che io dicevo che per situazioni più semplici (tipo rotazione
banners etc) può servire il mio caso, a me sembra che tu te la sia presa un
po' (troppo) a male perchè ho osato criticare il tuo lavoro.
Ognuno è libero di fare quello che vuole, per carità, ma io ho voluto solo
dire alla gente che esiste un modo migliore per fare la stessa cosa, in
molte situazioni, senza bisogno di svenare il server dalle risorse...


Ok per le specifiche?
si, ma continuo a non capire perchè modificare lo stesso record, e fare
tutto quel casino, quando un utente può tranquillamente avere i propri
record personali e modificarli in tutta sicurezza, anzichè essere costretto
a condivedere il tutto con altri...
quello che voglio dire è che è sbagliato l'approccio...


Se ho capito bene....
Esatto, in pratica comunque non consente di aggiornare il record perche' non
trova le condizioni preesistenti.
Il warning dice che non ha fatto le modifiche perche' la situazione era
cambiata.


 di giorni il server non avrebbe piů neanche un bit di memoria libera...
Scusa, ma non ho capito: cosa c'entra la "memoria" con i "record
bloccati"?


bloccati"?
si parlava di carico sul server.
Ho quindi precisato che anche se non lo fai tu, ci pensa IIS a scaricare
moduli non in uso...
