Newsgroup: it.comp.lang.javascript
Titolo: onUnLoad e registrazione in db

Ciao a tutti,
in un sito di interviste mi trovo a dover gestire il fatto che un utente
esca da una data pagina in modo diverso dal bottone che ho preparato.
Infatti per gestire il lock di un record all'entrata nella pagina uso un
UPDATE di un campo del recod  che me lo mette in stato "bloccato". Così se
un'altro utente cerca di aprire quel record otterrà esito nullo. Però, come
dicevo prima, se l'utente che ha bloccato il recod non esce dalla pagina nel
modo deciso il record rimane bloccato. Allora ho pensato, uso l'evento
onUnload di Javascrip per aprire in automatico una pagina ASP che si
connette al db, lancia un Update dello stesso campo del record mettendolo a
"sbloccato". La pagina che ha fatto l'update viene chiusa con
OnLoad="self.close()". Così per l'utente la cosa è trasparente (o quasi)
Ok, ma qual'è il prb?
Il prb è che sul mio pc (il sito è in intranet) tutto va che è una
meraviglia, vado su uno di un collega (molto più lento del mio e comunque
simile a tanti altri nell'ufficio) e spesso il record non viene sbloccato!!!
Ma perchè? Forse l'evento OnLoad scatta prima che il codice asp faccia
l'UPDATE? Non dovrebbe essere così perchè è lato server, mentre il codice
Javascrip è lato client...
Per favore aiutatemi
Grazie in anticipo e ciao a tutti.
##togli "era" dall'indirizzo di posta per inviarmi una e-mail##

 Grazie in anticipo e ciao a tutti.
impara un pò di logica della rete e poi inizia a programmare..
i record si devono bloccare in modo logico e non fisico in modo tale da
limitare i crash del sistema.
un sistema è quello del semaforo come detto prima
ma puoi usare altre forme.
l'importante che il record non venga bloccato dal file-system ma dalla
procedura di lettura-modifica
l'unico record che dovrebbe essere bloccato dal file-system è il record
semaforo.
il record semaforo dovrebbe riportare i dati univoci di esclusione.
ad esempio numero del record (o sequenza SQL) per i databases relazionali.
identificativo del terminale utilizzante, tipologia della funzione
richiamata (lettura , modifica, cancellazione), opzione di conferma
(conferma abilitata/negata).
poi devi creare una procedura di verifica dei semafori e controllo di flusso
delle conferme.
inoltre se vuoi devi inserire le priorità di esecuzione delle varie
conferme.

grazie tanto per la celerità della risposta,
purtroppo però la mia ignoranza non mi ha permesso di capirci molto:
Io uso ASP e con questo non capisco come poter fare il semforo che mi
consigli,
devo creare applicativi sul server? (mi sa che l'ho sparata grossa, vero?)
Il db che uso è SQL Server 2000 e nella procedure ADO non uso il blocco del
record bensì, come detto,
controllo lo stato di un campo del record.
Avresti voglia di darmi qualche dritta up po' più alla mia portata?
Ciao e grazie ancora.



bene.
allora crei un file extra che chiamerai come vuoi anche semaforo se ti va'.
la struttura del file dovrebbe essere la seguente ( ma ci puoi mettere
quello che più ti interessa)
campo 1 - Identificativo dell'utente (IP od altro)
campo 2 - identificativo dell'archivio su cui l'utente opera
campo 3 - tipo di accesso (lettura / modifica / annullamento)
campo 4 - livello  (più è alto meno è prioritario - 0 = administrator)
campo 5 - record su cui opera o sequenza SQL (se opera su più archivi
associati)
campo 6 - flag utilizzato ( se il record in oggetto è in uso da terzi e che
uso.  0-non utilizzato  1-utilizzato-lettura 2-utilizzato-modifica
3-utilizzato-annulla 4-già-modificato)
il campo 6 deve essere verificato prima della conferma di variazione od
annullamento
se diverso da 0 deve aprirsi una pop per avvertire che:
non può essere modificato/cancellato perché in uso,
deve essere ricaricato perché i valori sono nel frattempo variati
il campo 6 può essere modificato sia da l'utente che ha creato il record
semaforo che da chiunque acceda al database ed ha in comune i campi 2 , 3 e
5
naturalmente le priorità di variazione dipendono dal campo 4
prova in questo modo

 ha scritto:
Complimenti per la risposta :)
Si vede che a logica di DB te la cavi + che bene..
Cio' che hai detto e' tutto completamente giusto, il punto e' .. hai pensato
a come implementare una cosa del genere nel "vecchio" ASP?
--------------------------------
Inviato via 
http://usenet.libero.it

 a come implementare una cosa del genere nel "vecchio" ASP?
a Zerooooo ma con chi pensi di avere a che fare?  :-))))
scusa ma ASP ancora non lo mastico e non posso risponderti, dammi tempo...

 scusa ma ASP ancora non lo mastico e non posso risponderti, dammi tempo...
Lo supponevo (l'avevo dedotto dalla risposta).
Ma ASP e' ormai un linguaggio vecchio, infatti non vi sono problemi con un
codice del genere su PHP, JSP o 
ASP.NET
.
Inoltre anche il codice piu' banale in ASP, puo' occupare in modo pesante le
risorse di un server.


 risorse di un server.
non solo ma basterebbe un errore sul blocco record per richiedere
l'intervento del maintener (non ne sono certo ma ragiono per logica).
Scusa Zero ma perchè quando attacchimo noi due si finisce spesso [OT] ?

 Scusa Zero ma perchè quando attacchimo noi due si finisce spesso [OT] ?
..Perche' non siamo solo JScripters, ma abbiamo altri interessi comuni che
ci appassionano di piu'. :)
.. Dici che sbaglio?
P.S.
L'altro thread ha preso dimensioni apocalittiche ed un OT da spavento, ti
rispondo in mail da casa, ok?


 Scusa Zero ma perchè quando attacchimo noi due si finisce spesso [OT] ?
Sei in buona compagnia :-))))
-- 
Ciao, Riccardo
------------------------------------------------------------------------
http://www.jsdir.com
 ---- Bring Your Site To Life!!!!
------------------------------------------------------------------------
http://www.dev2dev.it
 - La rete ha connesso nuove particelle - D2D006
------------------------------------------------------------------------
 ----> itALY = it <----

 rispondo in mail da casa, ok?
Beh, se ne sono visti di peggio, e sinceramente la discussione mi piace :-)
A parte il fatto che finalmente vedo uno che ti tiene testa su argomenti 
concreti e non sulle "idee" come faccio io :-), anche se non ho mai avuto 
modo di addentrarmi nei meandri dell'ASM, dei TSR, ecc. personalmente non mi 
dispiacerebbe continuare a leggervi.


 concreti e non sulle "idee" come faccio io :-),
Infatti ci capiamo, non come con te che non riesco a spiegarti le cose, e si
finisce in semi-flames, tsk! :P


 piu'.
senti pur non conoscendo affatto ASP da quel poco che mi hai detto ho tirato
fuori questa soluzione:
ai campi già citati del record semaforo si aggiungono antri due campi
campo 7 :  contatore valori da 9 a 0 (0)=utente non più connesso
campo 8 : data ora dell'ultima connessione
poi a lato client (dato che server non è possibile effettuarlo) con un ciclo
periodico si aggiorna il campo 7 ed 8 del proprio record
chi deve agire a sua volta su tale record va' a leggere il semaforo e fa'
scalare di uno il contatore
(sempre ciclicamente) quando arriva a 0 lo azzera e può scrivere le
variazioni.
è chiaro che se un utente ha in modifica un record il proprio browser
periodicamente aggiorna i campi 7 e 8 impedendo agli altri di operare se
invece si disconnette o cade la linea gli altri utenti scalando il contatore
lo portano a 0 eliminando il record di blocco.
che te ne pare?

 che te ne pare?
Che il gioco non vale la candela, in quanto in fin dei conti l'evento
Session OnEnd fa gia' tutto questo senza dover montare su un "emulazione di
ping".
In sostanza, se dopo tot non riceve input dal client, fa scadere la sessione
(e quindi invoca l'evento chiudendo il record rimasto appeso).
Il tuo metodo di scalo, inoltre, e' secondo me rischioso, in quanto
potrebbero verificarsi condizioni in cui il record rimane appeso cmq. Se l'
"utonto" esce brutalmente dal browser e nessun altro accede allo stesso
record, non essendoci alcun evento che faccia scalare il campo relativo, non
viene sbloccato.
No, tu usi approcci ragionevoli e giusti per la "programmazione canonica",
per cosi' dire, ma che male si applicano ad ASP (soprattutto ad ASP..).
Anche perche' la tua soluzione prevede accesso a diversi campi da piu'
utenti, e quindi dovresti avere una variabile di applicazione o un file di
testo condiviso, ma a questo punto dovresti lockare anche questi per evitare
sovrascritture contemporanee.. Il codice che ne vien fuori incomincia a
diventare un po' troppo per il tipo di problema che si affronta.
La soluzione migliore in tale ambiente, e' appunto gestire il tutto dalla
Session, stabilire a tavolino "quanto" un utente puo' stare senza farsi vivo
sul server e mantere il record bloccato, e settare il timeout della Sessione
di conseguenza.


 di conseguenza.
aaaaaaaahhhhhh!!! funza così?  come và và! si assume che l'efficienza non
sia così importante.
con grossa mole di lavoro il sistema va' in tilt allora. o ci si addormenta
prima.
ho serie difficoltà a ragionare in simil modo.

 ho serie difficoltà a ragionare in simil modo.
Questione di conoscere l'ambiente ed i suoi limiti.


 Questione di conoscere l'ambiente ed i suoi limiti.
certamente, il problema nasce nel dover "contorcersi" per mantenere una
identica struttura di gestione database interna tenendo conto di accedere a
realtà così differenti.
purtroppo io ragiono a strati
e chi progetta lo strato finale (cioè quello utilizzato dai programmatori)
deve prevedere che gli stessi mantengano lo stesso stile su tutte le
piattaforme. è onere di chi interfaccia l'accesso ai vari file system creare
delle routines standard.

 delle routines standard.
Bella utopia :) In ogni caso i programmatori non ragionano tutti allo stesso
modo, inoltre vi sono diversi approcci e stili anche nella programmazione
(strutturata, ad oggetti).
Cmq puoi ovviare a tutto cio' con dei wrapper, che si conformino al tuo
stile.
