Gestire la concorrenza in ASP

[archimede]

Utente 1 = connesso da 60 minuti alla pagina non ancora inviata

Utente 2 = appena connesso.

Nella pagina di Utente 2 c'è scritto: se Utente 1 ha il lock >10 minuti ALLORA Utente 1 unlock e Utente 2 lock.

Insomma, è possibile subordinare il lock a un fattore tempo e toglierlo dalle pagina di altri accessi?

E (caso limite, d'accordo) che succede se arrivano Utente 2 e Utente 3 e fanno la stessa richiesta contemporaneamente?

Alessandro

[Dylan666]

LOL Ma questo caso limite che differenza fa con il caso in cui pure lo script di prima sia lanciato in contemporanea? Cio se invece che Utente 2 e 3 arrivassero insieme 1 e 2 ?

[archimede]

"Lo script di prima" quale?

Comunque mi sa che siamo andati parecchio OT...

Alessandro

[Dylan666]

Quello proposto dal mio secondo sito.

Cioè, tu mi hai posto il prblema dei 2 "unlock" lanciati contemporaneamente dalla mia aggiunta, ma non è lo stesso problema che si verificherebbe con 2 "lock" lanciati in contemporanea da quel codice?

[archimede]

Certo, ma io non ho mai sostenuto che fosse la soluzione ottimale.

Alessandro

[piercing]

Mai sentito parlare di transazioni?

Tutti a scuola... a studiare ADO di Microsoft...

[archimede]

Mai sentito parlare di transazioni?

Tutti a scuola... a studiare ADO di Microsoft...

Scusa ma mi sfugge il nesso: da quel che ne so le transazioni aiutano se devi fare diverse operazioni su diverse tabelle e vuoi avere la certezza che vadano tutte a buon fine o, in caso di errore, siano tutte annullate.

A parte ciò, anche ammesso che le transazioni ADO ti possano in qualche modo aiutare ad evitare il problema di cui stavamo discutendo con Dylan, non possono evitare il problema dell'"update perso" al quale mi riferivo originariamente.

Senza offesa, neh?

Alessandro

[piercing]

archi... cos'è l'update perso...???

ovvio che se due utenti modificano lo stesso record.... vince quello che aggiorna per ultimo...

circoscrivere una serie di istruzioni SQL in transazione evita per l'appunto questo problema...

[Swalke]

PJ, non avevo pensato a uno scenario come quello del cinema! In effetti ai ragione!

Archimede, hai ragione il where nell'INSERT non c'entra niente... ...è un po' che non maneggio SQL, comunque il mio discorso non cambia se togli il where e aggiungi di inserire l' ID incrementato di 1.
Con memoria condivisa si intende la memoria che il server assegna alle risorse condivise di più processi in esecuzione. Sostanzialmente è RAM. La memoria non condivisa è la memoria che contiene le variabili "personali" allocate dai singoli procesi.
Parlando del tuo esempio, credo che iniziamo a parlare della stessa cosa ^^, anche se tu hai usato un update la questione è la stessa. Quello che vorrei capire io è proprio quel "qualche modo" per bloccare i rekord.
Quando un utente da un submit, si arriva alla pagina che contiele l' SQL che inserisc il record con ID+1 . Ecco prima della stringa SQL deve esserci una lok così che nessun altro possa maneggiare l'ID da incrementare mandando tutto a vacche! Insomma tra lok e unlok passerà solo una frazione di secondo! Non si pone il problema "ora di pranzo" (nel mio caso).
Il tuo caso 2 invece non mi sembra (e sottolineo sembra) adeguato al mio sistema... ...non mi sto a dilungare.
...so benissimo che access non è il massimo ma devo costruire un applicazione per me stesso e per ora mi basta e non mi da problemi, anzi.

X tutti : grazie mille!

Forse a breve avrò la soluzione del mio problema... ...ho scoperto che un mio amico ha avuto lo stesso mio problema facendo uno stage all'universita! Mi farò dire come l'ha risolto e poi posterò la risposta... ...magari vi interessa. Ho anche la sensazione che qualcuno si sia spinto anche un po' altre a quello che mi serviva e forse quando vedrà la mia risposta si dirà "aaaaa, ma allora ti serviva sapere solo quello!!!"

Comunque grazie a tutti!

[archimede]

archi... cos'è l'update perso...???

T0: l'utente A seleziona i dati del record 1 ed inizia a modificarli
T1: l'utente B seleziona i dati del record 1 (vede le stesse informazioni che A vedeva inizialmente) ed inizia a modificarli
T2: l'utente A invia le proprie modifiche (che vengono correttamente registrate)
T3: l'utente A verifica che le proprie modifiche siano state correttamente registrate e va a casa
T4: l'utente B invia le proprie modifiche (che vengono correttamente registrate)

Se in T4 non c'è nessun controllo che i dati del record sono cambiati dopo T1 l'utente A avrà di che lamentersi.

ovvio che se due utenti modificano lo stesso record.... vince quello che aggiorna per ultimo...

Sarà anche ovvio, ma per alcuni può essere altrettanto indesiderato.

circoscrivere una serie di istruzioni SQL in transazione evita per l'appunto questo problema...

Continuo a non capire come...

Alessandro

[archimede]

comunque il mio discorso non cambia se togli il where e aggiungi di inserire l' ID incrementato di 1.

<snip>

anche se tu hai usato un update la questione è la stessa.

<snip>

Quando un utente da un submit, si arriva alla pagina che contiele l' SQL che inserisc il record con ID+1.

Scusa ma secondo me tra inserire un nuovo record e modificarne uno già esistente c'è una bella differenza (relativamente al problema di concorrenzialità da te posto).

Se il tuo unico cruccio è l'ID da assegnare ai nuovi records, ho buone notizie: Access ha un tipo di campo Autonumber che gestisce automaticamente senza bisogno che tu faccia nulla da codice.

HTH.

Alessandro

[Swalke]

Scusa ma secondo me tra inserire un nuovo record e modificarne uno già esistente c'è una bella differenza (relativamente al problema di concorrenzialità da te posto).

D'accordissimo che update e insert erano diversi ma nel tuo update e nel mio insert vi era comunque lo stesso problema di record sovrascritti (da te detti "update persi"). Comunque credo che adesso il mio problema sia chiaro no?

Riguardo ad access mi stai dicendo che il DBMS grazie ad Autonamber (spesso usato come chiave primaria) garantisce già su eventuali problemi di concorrenza? Cioè in tal caso è il DBMS che si fa carico di gestire in maniera corretta scritture contemporanee?
Se è così buono a sapersi!!! Questa è la risposta + preziosa che ho avuto fino ad ora!!!
...ad ogni modo preferirei avere una tecnica meno DBMS dipendente ^^

[Swalke]

...spero che questa mia parentesi non faccia deviare la conversazione, ma già che ci sono avrei una domanda:

A proposito del campo contatore di access proposto da Archimede: questo tipo di campo può essere un "intero lungo" e quindi può arrivare fino a 2.147.483.647. Ora... ...lo so che è uno sproposito ma in certi casi potrebbe non bastare e quindi mi chiedevo cosa avviene nel remoto caso in cui si "sfora"!

[piercing]

archi... cos'è l'update perso...???

T0: l'utente A seleziona i dati del record 1 ed inizia a modificarli
T1: l'utente B seleziona i dati del record 1 (vede le stesse informazioni che A vedeva inizialmente) ed inizia a modificarli
T2: l'utente A invia le proprie modifiche (che vengono correttamente registrate)
T3: l'utente A verifica che le proprie modifiche siano state correttamente registrate e va a casa
T4: l'utente B invia le proprie modifiche (che vengono correttamente registrate)

Se in T4 non c'è nessun controllo che i dati del record sono cambiati dopo T1 l'utente A avrà di che lamentersi.
Alessandro

questo succede in qualunque applicazione... soprattutto su web... ma siccome si presume che entrambi stiano scrivendo gli stessi dati... alla fine il risultato non dovrebbe cambiare... se non per il fatto che hanno fatto in due lo stesso lavoro...

sinceramente qualunque soluzione con flag di stato rischia di essere altamente rischiosa... causa blocchi di record a tempo indeterminato...

come sempre su web in questi casi ci vorrebbe un keepalive che passi sul client alcune variabili "di stato"... soluzione che potrebbe essere sempre possibile, ma sicuramente di difficile gestione... bisognerebbe valutare quanti casi di concorrenza sarebbero effettivamente possibili...

l'aggiornamento vero e proprio del record infatti avviene in un istante solo (per quanto sia assolutamente auspicabile l'utilizzo di transazioni per farlo), il problema è che un utente può anche tenere aperta la maschera per tutto il giorno... e dare l'invio dopo 8 ore.... ritengo assolutamente peggio il fatto che per 8 ore consecutive io mi possa trovare lo stesso record bloccato da chicchessià solo perchè si è scordato di chiudere la maschera...

potrebbe sempre essere possibile un controllo confrontando se i dati iniziali caricati nella maschera (prima della modifica) corrispondono ai dati iniziali dell'aggiornamento del record... altrimenti messaggio di errore dicendo che i dati sono cambiati prima dell'aggiornamento... e questo non è difficile da farsi... e l'utente a quel punto ne viene informato...

la staticità delle soluzioni web infatti deve sempre far inventare qualche barbatrucco per questo tipo di situazioni...


per quanto riguarda il campo autonumber... non credo che sia necessaria una chiave se davvero quel numero dovrà essere superato... cmq se davvero dovesse essere necessario... si può solo cambiare DB, o gestire una soluzione software ibrida... ad esempio un md5 su una data comprensiva di millesimi di secondo... (che cmq non è sicura... ma a quel punto entra in ballo la statistica...)

[archimede]

...ad ogni modo preferirei avere una tecnica meno DBMS dipendente ^^

Why?

questo tipo di campo può essere un "intero lungo" e quindi può arrivare fino a 2.147.483.647. Ora... ...lo so che è uno sproposito ma in certi casi potrebbe non bastare e quindi mi chiedevo cosa avviene nel remoto caso in cui si "sfora"!

Avrai problemi (di altro genere) con Access molto prima di raggiungere quel limite, per cui non mi preoccuperei più di tanto.

Alessandro

[Swalke]

Why?

Perchè così qualsiasi DBMS uso, posso usare quella tecnica!

Avrai problemi (di altro genere) con Access molto prima di raggiungere quel limite, per cui non mi preoccuperei più di tanto.

PEr esempio... ...giusto per sapere cosa dovrò afrontare ^^

[archimede]

Perchè così qualsiasi DBMS uso, posso usare quella tecnica!

E' la risposta che mi aspettavo.

Forse molti dissentiranno, ma il mio parere (che in realtà non è mio, ma al quale ho aderito incondizionatamente) è che ambire alla cosiddetta "indipendenza dal db" sia un atteggiamento autolesionista.

La logica è: scrivo un applicativo per Access (o qualsiasi altro RDBMS) in modo che se domani voglio cambiare DB non mi devo preoccupare di cambiare il codice.

Siccome ogni db è diverso dall'altro, per raggiungere quell'obiettivo dovrò scrivere del codice che non usa nessuna caratteristica "proprietaria".

In tal modo:

1) Quando cambierò db, dovrò comunque mettere le mani al codice, perchè alcune differenze sono proprio nell'architettura di base (la logica che va bene per un db per un altro non può funzionare)

2) Non sfrutterò al 100% (ma neanche al 70%) le potenzialità del prodotto, rinunciando, in definitiva, alle features che garantiscono maggiori performance, scalabilità e affidabilità.

Morale: è un illusione ottica pensare di scrivere un applicativo (di un certo spessore) che gira in modo analogo su qualsiasi db senza toccare una riga di codice, per cui tanto vale sfruttare al massimo gli strumenti che ogni db ci mette a disposizione.

Avrai problemi (di altro genere) con Access molto prima di raggiungere quel limite, per cui non mi preoccuperei più di tanto.

PEr esempio... ...giusto per sapere cosa dovrò afrontare ^^

Beh, intanto mi pare che ci sia un limite (teorico, io non ci sono mai arrivato) di 2GB nelle dimensioni totali del db (A2000 o sup.): calcola le dimensioni della tabella e vedi quanti record ci possono stare al massimo. Sarei sorpreso se ti risultasse un numero vicino a 1 Miliardo, e anche così saremmo al 50% della capacità di un Contatore.

Inoltre non ho idea (non avendo mai raggiunto tali limiti) di come possano essere i tempi di risposta di un mdb così grande, ma non mi aspetterei sorprese piacevoli neanche su questo fronte.

Infine un numero così elevato di records potrebbe/dovrebbe essere indicativo anche di un numero elevato di utenti: non ricordo al momento il numero teorico di accessi contemporanei supportati da Access.

Se la teoria non convince, proviamo un approccio più pragmatico: stiamo parlando di 2 miliardi di records, giusto? Bene, supponendo di inserire un record al secondo, arriverai al limite più o meno nel 2070 (se ho fatto bene i conti): se sei capace di scrivere un applicativo che ha una vita così lunga, abbiamo un posto per te qui in azienda!

HTH.

Alessandro

[archimede]

calcola le dimensioni della tabella

calcola le dimensioni del singolo record...

Alessandro

[Swalke]

Sono pienamente d'accordo con te sulla questione "trovare un codice indipendente dal database".

Ma per quello che mi riguarda, voler imparare la tecnica ASP per gestire la concorrenza a un record non centra una beneamata fava con questo!

...anche perchè il tipo di tecnica che adopererò agirà su un oggetto ADO.

Per la questione relativa al numero di utenti e numero di accessi:
se ho capito bene stiamo parlando della limitatezza di un campo di tipo contatore influenzata da un dimensione limitata del DB giusto?

Il fatto è che (sempre se ho capito bene) tu stai presupponendo che se il mio campo contatore arriva ad esempio a 2000 allora io ho 2000 record nel database.
Nella mia tabella ci sono solo un centinaio di record perchè i nuovi vengono aggiunti e i vecchi vengono tolti (secondo una politica FIFO diciamo)... ...così che io mi ritrovo sempre con un database leggero ma (usando un campo contatore) ho dei record con valore del contatore sempre crescente.
Cosi nel 2050 avrò sempre un database leggerissimo ma rischio di sforare dal limite del contatore!

Quindi se proprio vogliamo per me usare acces nella mia applicazione non è un problema fin che non esaurirò i valori di contatore disponibili!

[archimede]

Ma per quello che mi riguarda, voler imparare la tecnica ASP per gestire la concorrenza a un record non centra una beneamata fava con questo!

Ok, ti faccio i miei più sinceri auguri.

Alessandro