Newsgroup: it.comp.appl.access
Titolo: un altro modo affascinante per evitare i conflitti

Fare modifiche dei record ASINCRONE.
Bello, bellissimo. L' ho "immaginato" mo' mo'.
Ovvero (a grandi linee) il client "accoda" sul server una
richiesta di modifica  di un certo record X e si mette in attesa
della risposta del server.
A sua volta la macchina che ospita il programma
"server" (per capirci) ha un orologio che ogni tot
legge le richieste di modifica e le esegue.
Una per volta => Problema risolto.
Ovviamente le richieste di modifica possono
contenere istruzioni particolari, come per esempio :
"modifica a patto che i dati siano ancora questi,
altrimenti no" E cosi' via.
Mannaggia, avessi tempo darei il soffio della vita
a questa meravigliosa creatura.
Magari alla prossima applicazione.
Un abbraccio a tutti.


Hai mai sentito parlare di ACID: Atomicità, Consistenza, Isolamento, 
Durabilità
Vedi transazioni e livelli di isolamento...
E' la base nel "regime" di concorrenza e non esiste un modello universale
Per dirtene una: Oracle usa il blocco ottimistico, SQL Server usa il 
pessimistico
Ciao
-- 
Daniele
Rispondere scartando OneEDP, spam e 32

 Ciao
Radicale usa l' "arrangistico" :D 


che credo sia comunque il modello di piu' ampia diffusione.

Atomicità, Consistenza, Isolamento,Durabilità
Si, si ... 'o saccio.
Ma alla fine " siempre 'o server " s' ha da move.



Ehmmm Umoristico direi :-)


radicale 004 ha scritto:

Ma non è così che ragionano già i motori server? UPDATE tizio SET blablabla
WHERE [Tutti i campi=alla select precedente]??? O il campo TimeStamp par MS,
che di fatto fa la stessa cosa senza tirar su tutto.....Se lo fai a
mano.....auguri! Praticamente si tratta di avere una struttura temporanea PER
OGNI TAB che può essere updatata!!!!!! Per me è terrificante.....
-- 

Per me è terrificante.....
Naa ...
Basta ce crei *una* "coda di richieste" fatta coi
controcoglioni e un software altrettanto paraculo
eseguito dal server che la legge e fa.

 Radicale usa l' "arrangistico" :D
"ACID" ti e' particolarmente consono come
termine. :D
(questa e' buona , ammettilo)
Dimostra adesso che sono un arrangione e che
quello che ho scritto sono minkiate.
Tenendo in conto le mie successive risposte
e quelle i Fair87.
No ma mica per tigna, eh ! Non fraintendere !
E' perche' voglio imparare qualcosa.

 E' perche' voglio imparare qualcosa.
;) infatti scherzavo... era per creare un nuovo filone d'azione che andasse 
al di là di Oracle e SQL... ho creato il filone "Radicale" (che come diceva 
anche Alessandro è quello poi usato dai più... nessuno escluso - nessuno - ) 
;)...
...però non capisco perchè a te piaccia tanto complicare le questioni... 
snaturare i prodotti per ricrearli mi sà di NoSense, però giuro ne apprezzo 
lo spirito esplorativo :D 

> Un abbraccio a tutti.
Sei giunto alla SPIA che resta in ascolto di cui ti ho parlato tempo fa in 
un altro 3d?... bene bene... vedo che progrediamo :D
Scherzi a parte, vuoi che sia onesto?... ciò che mi fa più paura in ciò che 
hai scritto, è la parola "OROLOGIO"... cioè se non ho capito male tu 
vorresti dare a un sistema "fragile" come il timer di access (che si blocca 
ogni 3 x 2), un compito così delicato?... sarà anche pensato con i 
controxxxi ma la piattaforma lo rende di per sè non gestibile, andrebbe in 
errore e in crash troppo in fretta... io rabbrividisco già solo a pensarlo.
Ma forse ho capito male. 

 ha scritto nel messaggio 
news:6Cafo.232234$813.1...@tornado.fastwebnet.it...

Uà e che lo dici a fare!!! ...è il mio pane quotidiano :D 


E gli altri che fanno aspettano che il paraserver li prenda per il ... :-)
Prova ad immaginare con 1, 100, 1000000000000 utenti
Anche con due connessioni aperte andresti in dead lock
Anche questo è stato inventato da tempo:
http://technet.microsoft.com/it-it/library/bb522893.aspx
http://en.wikipedia.org/wiki/Microsoft_Message_Queuing
questo per esempio è impossibile con Access 
http://msdn.microsoft.com/it-it/library/ms172133.aspx
, ma ha dei potenziali
oltre alle transazioni.
Ti posso dire per esempio che in alcune realtà importanti di impresa 
alcuni sviluppatori hanno pensato bene per togliersi da ogni impiccio di 
attuare la "serializable". Questo significa puntualmente che se un 
utente è in pausa caffè gli altri devono aspettare. Gli strumenti ci 
sono. bisogna usarli, ma costa fatica
Ora però sono OT è il "filone" non è decisamente "arrangistico" :-)
Comunque sperimentare ed esploarare sono gli ingredienti giusti.



wrote:

No hai capito benissimo.
Infatti il punto debole e' quello. Me ne rendo conto.
Pero' spiegami, ti prego :
come fa il server ad eseguire la richiesta del client ?
Cioe' voglio dire, visto che le richieste non vengono
(nei sistemi veri) serializzate da un timer, come fa il
server a essere "svegliato" ? Forse il client riesce
a generare un interrupt su server ? Non credo. Allora
come ?

 Anche con due connessioni aperte andresti in dead lock
Scusa ma perche' dici questo ?
Ma stiamo parlando della stessa cosa ?
Immagina :
un client sulla macchina C1,
un client su C2,
...
un client su Cn
una macchina intermedia Mi,
un server Ms.
Ogni client, quando fa una richiesta R al server,
non fa altro che chiedere a Mi di aggiungere un record
ad una tabella Ti con i dati della richiesta.
E basta.
Per esempio :
R = "mandami un record che soddisfi questi criteri"
E poi si mette in attesa OPPURE (a seconda del
tipo di richiesta) si mette a fare altre cose
Il server ogni tot secondi si legge la tabella Ti
e guarda se e' arrivata una richiesta.
Se si la esegue e segna il record come eseguito.

 Se si la esegue e segna il record come eseguito.
Il problema non è la lettura, è rendere consistene il dato che un altro 
utente sta scrivendo e che ancora non ha confermato.
Della serie la accendiamo... e nel frattempo finché non viene 
"committata" gli altri aspettano



L'ascolto non avviene con temporizzatori... ma con delle code a
priorità di chiamata... ma c'entrano poco con quello che hai
intenzione di fare tu visto che intendi farlo con Access.
Io ti suggerisco altro... hai presente MSN?... quello è un
ASCOLTATORE.
Il server (nel caso specifico client/server perchè riceve ma invia
anche) resta in ascolto su porte specifiche, e ogni transazione su
quella/e porta/e è processata in modo particolare...
ecco, tu quello potresti eventualmente usare come metodo... e potresti
farlo utilizzando il Winsock. Sembrerà assurdo, ma tu hai bisogno
(imho e se ho capito bene) dello stesso sistema che usa una chat per
permettere la comunicazione tra utenti.
(Es. 
http://www.visual-basic.it/articoli/ldlChat.htm
)
Fammi sapere.


Non per nulla l'oggetto "Connection" è uno degli oggetti più importanti 
e indispensabili in un databeis..
Ogni volta che avvii access c'è un'implicita apertura all'oggetto 
connection del progetto corrente.



A proposito del filone "arrangiamoci" o "anneghiamoci". hai mai 
utilizzato questa gestione 
http://www.winfxitalia.com/articoli/windows-server/utilizzare-message-queue-scalare-applicazioni.aspx
 
?
In pratica mi piacerebbe con access riuscire a metterlo in "ascolto" 
utilizzando quete librerie fornite a corredo dal win 95 e gratuite 
(visto che non abbiamo .net per il servizion query notification)
Ciao


 ?
No, ma mi pare interessante... lo leggo volentieri, e se riesco
(appena ho un attimo da didicarci), volentieri ti passo i risultati


Credo sia una possibilità che promette bene...
mi metto in "ascolto"...
Ciao e grazie


 
mi sfugge una cosa...
access messo 'in ascolto' non diventerebbe qualcosa di simile a un rbdms?
(vagamente simile, eh...)
ma non conviene allora installarsi un msde o simili?
-- 
Paolo opg
BE AWARE that this post uses a fake reply-to address
to contact me write to:
janickg ( at ) hotmail ( dot ) com
--


No. Il concetto e metterlo ascolto di un server su elaborazioni 
asincrone inviategli in precedenza, in più riuscire a determinare il 
verificarsi di alcuni eventi innescati da altri client. Attualmente con 
i mezzi a disposizione, a me noti, genera roundtrip onerosi


 intenzione di fare tu visto che intendi farlo con Access.
Si ma a prescindere da Access, solo per capire :
come funziona questa faccenda delle code a priorita' di
chiamata ?
Qual' e' il meccanismo ?


Siamo proprio OT OT :-)
E' come chiedere "cos'è un RDBMS"... ma dal punto di vista ... 
"internals" 
http://www.sqlserverinternals.com/
Cos'è un RDBMS penso che lo sai, ma vorresti scavare...
In bocca al lupo
Ciao


 ha scritto nel messaggio 
news:de535597-5bd7-4af4...@f42g2000yqn.googlegroups.com...




----------------
Detta in modo elementare, il meccanismo è più o meno proprio quello che ti 
sei proposto... ma il tutto non avviene con i timer, o almeno non i timer 
"tipo" come li si immagina .
Sono i protocolli di comunicazione su cui si basano i S.O. a svolgere tali 
funzioni, protocolli che (essendo sempre attivi - una sorta di "servizi" 
sempre avviati - ), tengono i sistemi in perpetuo "ascolto" di tutte le 
transazioni che avvengono da e verso gli stessi (immagino ad esempio il 
protocollo TCP/IP).
Ascoltare eventi e tradurli (alla fine sempre input binari sono), permette 
anche (a chi se lo aspetta) di ricevere risposte (quindi comportamenti) 
adeguate da parte dei server, che svolgono o meno per questo azioni 
piuttosto che altre (Es. pingare una macchina esterna, vuol dire interrogare 
un protocollo che risponde a una sollecitazione tradotta).
Su due piedi non saprei spiegartelo meglio.

Il problema non è la lettura, è rendere consistene il dato che un >altro utente sta scrivendo e che ancora non ha confermato.
Ma e' semplice, basta introdurre delle regole.
Comunque dai ... Non voglio avere ragione per forza non
fraintendermi. Io sono solo desideroso di capire.


Assolutamente no. L'impressione che percepisco è che sei desideroso di 
scoprire.
Il rischio è che mi capita spesso di proporre soluzione che sono state 
già ampiamente dibatture e predigerite millenni orsono.
Cmq sull'internal che ti ho proposto delle risposte le trovi.
Ciao
