Salve a tutti
qualcuno sa dirmi cosa succede in un caso come quello che vi descrivo qui sotto :
data una webApp
in un form ho un tasto nel cui evento click ho del codice che lavora ( per ipotesi ) aggiornando 1000 record di un db tipo
rs=sesssion.db.sqlselect(“select * from cippa”)
do until rs.eof
rs.edit
rs1=session.db.sqlselect(“select sum(a) as somma from pippa”)
rs.field(“c”)=rs1.field(“somma”)
rs1.close
rs.update
rs.movenext
loop
ipotizziamo che tutto la procedura (1000 record) richieda 4 minuti
ipotizziamo che il client connesso alla webApp chiuda il suo browser dopo 1 minuto e che abbia fatto girare la procedura su 250 records
ipotizziamo che subentri l’eveto session.timeout
cosa accade alla procedura a cui mancano da processare altri 750 records ???
seconda domanda :
a suo tempo mi dissero di usare i thread …ma qualcuno sa darmi indicazioni a tal riguardo, tipo cosa sono, come si comportano, sopravvivono nche alla chiusura del browser ???
ciao a tutti, jury.
Ciao Jury,
in linea di principio se una routine impiega tempo, questa terr impegnata alcune risorse del server, non risponder immediatamente alle richieste nella sua sessione, le altre continueranno a rispondere e solo alla fine di tutte le operazioni verr rilasciata la sessione.
Un thread una porzione di codice che viene eseguita indipendentemente, vale a dire che il controllo riprende immediatamente con l’operazione successiva a thread.run mentre il codice in run viene eseguito.
L’unica controindicazione ad usare i thread in una webApp che questo deve “intervenire” poco, ovvero evitare blocchi (#pragma) perch convive (cooperative thread) con le altre operazioni e gli utenti potrebbero avere una applicazione poco reattiva.
grazie per la risposta, ma continuo ad avere dei dubbi.
se il client connesso alla mia webApp, dopo aver cliccato sul tasto che esegue quel ciclo, e questo lo dovrebbe fare su 1000 record = 4 minuti, se il client connesso chiude il browser o peggio si interrompe la connessione tra client e webapp dopo 1 minuto… la mia subroutine viene interrotta o continua a fare il suo dovere per tutti e 1000 i records ?
forse mi suggerivano di usare un thread perch questo ha una sua autonomia indipendente dalla sessione ???
ancora grazie, ciao jury.
Dovresti usare un thread a livello di app
Ovvero nella finestra istanzi una sottoclasse di thread che contiene un riferimento alla sessione (parametro, non l’oggetto o al massimo una weakref), e il codice da eseguire (quindi pronta ad essere eseguita), la sottoclasse generica deve avere anche un evento che indichi la terminazione del thread.
Nella app metti un dictionary che andrai a popolare con i vari thread di questa sottoclasse base (nel senso che saranno a loro volta sottoclassi con i vari codici da eseguire)
Nella app metti due metodi uno per gestire la terminazione dei thread e un per aggiungere un thread (che lo aggiunge al dictionary al fine di tenerli in vita, aggiunge il riferimento al metodo di terminazione e lancia il thread)
Il metodo di terminazione elimina il thread dal dictionary e se presente ancora la sessione invia un messaggio alla sessione.
In debug questo non riesci a vederlo perch l’applicazione viene terminata alla chiusura dell’ultima sessione; in esecuzione da singolo funziona.
Chiaramente un metodo alternativo, ma forse meno versatile quello di richiamare una applicazione helper.
Chiaramente il vantaggio in questo caso il solito: l’uso di eventuali processori a disposizione in quanto proprio un processo indipendente.
porca miseria !!! qui altro che semplificare lo sviluppo di applicazioni web !!! a me pare che la cosa sia molto piu complicata del dovuto !
se per ogni gestione o manipolazione di dati devo fa riferimento ad un ingarbuglio di quel tipo o fare riferimento a applicazioni esterne diventa veramente un casino !! anche solo per la gestione della visulaizazione degli eventi che si succedono .
Ma nessuno ha mai avuto problemi come quello da me esposto ???
non mi sempbra che nel manuale utente di rs o xojo si faccia mai riferimento a casi in cui connessione o chiusura del browser debbano essere gestiti in modo particolare .
Poi mi dicevi di thread a livello di applicazione… , ma i thread non sono tutti a livello applicazione ? o sono anche questi influenzati dalla sessione ??
Una applicazione web funziona diversamente da una applicazione desktop.
Se in una applicazione desktop usi un thread puoi chiudere l’applicazione (anche con il thread in esecuzione), ma hai la possibilit di verificare se il caso o meno di chiuderla a livello software (ad esempio sono a met dell’aggiornamento del db)
In quella web ogni sessione una applicazione a parte e non hai modo di non farla chiudere per cui se fosse a livello di pagina o di sessione verrebbe interrotta comunque a met (almeno per quello che so e ho potuto vedere, poi se ci sono metodi diversi non so)
L’app invece continua ad esistere, per cui il tuo thread potrebbe continuare a vivere.
Il mio suggerimento era relativo al fatto che non controllando l’esecuzione a livello di app, dovevi avere un modo per permettere ai thread (nel mio esempio potevano fare qualsiasi operazione tu voglia) di vivere, eseguire e terminare in modo pulito (senza rimanere in memoria o altro)
L’helper un modo per alleggerire il peso sul processore (sfrutti il multicore), la gestione ovviamente diversa ma pu essere una soluzione, visto che indipendente (se vuoi) dal tempo di vita della app.
Infine sulla posizione del thread:
I thread sono oggetti, vivono dove lo metti e per la durata (potenziale ovviamente) dell’oggetto che lo contiene; non sono oggetti che vivono in un mondo a parte
Quando in una app desktop lo metti in una finestra quel thread esiste fintanto che esiste quella finestra.
Riassumendo:
Il problema esiste a livello di run in debug. Se compili la app con Xojo non hai questo problema, posto che il thread “lungo” ha la possibilit di continuare il suo lavoro (ovvero non nella sessione)