Newsgroup: it.comp.appl.notes-domino
Titolo: Lock del record

Salve a tutti...
E' la prima volta che intervengo, anche se vi seguo
(saltuariamente) da un pò, in genere preferisco
cavarmela da solo ma....
Probabilmente il mio problema è irrisolvibile, vista
la "filosofia" di Notes, ma ho l'esigenza di fare il
lock di un record (cosa banalissima su altri
linguaggi) per evitare un accesso contemporaneo.
Per essere più chiari, ho un contatore letto e
incrementato ad ogni accesso, ovviamente se due utenti
lo fanno contemporaneamente, leggono lo stesso numero.
E' possibile mettere il secondo utente in attesa che
il primo abbia salvato?
Grazie da parte del mio fegato....
ADC
______________________________________________________________________
Do You Yahoo!?
Il tuo indirizzo gratis e per sempre @
yahoo.it
 su 
http://mail.yahoo.it
-- 
Posted from 
web6008.mail.yahoo.com
 [128.11.23.70] 
via Mailgate.ORG Server - 
http://www.Mailgate.ORG

>ma ho l'esigenza di fare il lock di un record
in questo casi io uso due metodi: il primo che semplicemente impedisce il
salvataggio  di un documento e attende che l'evento save finisca , e il
secondo che invece avverte l'utente che il documento č in uso au un altro
utente , e chiude il documento.
metodo 1 ____________________________
si basa sui 2 parametri della funzione save: esiste un unico documento
contatore in una vista , e l'incremento del campo contatore avviene in modo
univoco:
Set view=db.getview("Prog_segn")   'vista contatore
 Set doc=view.getfirstdocument ' il documento contatore
Do
  prog=doc.Prog_segn_mod(0)
  uidoc.document.Prog_segn = prog ' assegno il valore dove mi serve ....
  doc.Prog_segn_mod=prog + 1 ' aumento il contatore
 Loop While Not doc.Save(False,False)   ' salvo solo quando nessuno sta
salvando.
_________________________________________________________________
metodo 2 __________________________________
un poco piů lungo , io l'ho copiato dall'area di download di 
notes.net
 , non
lo posto perchč c'č una libreria di script un pň lunghetta; in sostanza , si
tratta di settare  all'apertura del documento un campo LOCK , e i successivi
che ci accedono non possono piu'. se ti serve mandami una mail e io ti
spedisco il codice.
-----
| Paolo Armando
| Programmatore Notes&Domino - Orgoglioso di esserlo!
| 03475091395
-----
-- 
Posted from [213.255.46.171] 


Avevo già risposto, ma evidentemente la risposta si è persa nei meandri 
della rete.....
Allora... Grazie Paolo Armando (ma quale è il nome?) per la "dritta" ho 
provato il "Metodo 1" e funziona egregiamente, ma mi farebbe piacere dare un 
occhiata (a scopo didattico)anche al "metodo 2".
Alla prossima...
Ciao
ADC
_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at 
http://www.hotmail.com
.
-- 
Posted from [212.216.216.27] by way of 
f134.law14.hotmail.com
 [64.4.21.134] 


Il metodo che mi sono inventato io e che da 4 anni ho sparso in giro per 
comuni anche grossi ...Arese, Sandonà, Rosignano .... senza nessun 
problema.
Si basa su concentti di semaforo e sezione critica.
In dettagio servono 2 documenti: il doc semaforo e il doc Numero.
Lo script che deve leggere e aggiornare il numero deve obbligatoriamente 
prendere il docSemaforo (se non lo trova è già loccato) se lo trova deve 
subito loccarlo, ovvero settare in un campo READER il nome dell'utente che 
eseguie lo script (rende inaccessibile il doc semaforo ad altri) mentre lo 
ha loccato può accedere al doc numero e aggiornarlo.
Prima di finire lo script deve impostare nel campo READER un valore di 
sblocco ...io uso un gruppo ALL a cui appartengono tutti gli interessati.
Se il discorso ti interessa solo per appilicazioni WEB puoi usare JAVA per 
codificare agenti e usare la primitive di lock e unlock disponibili...

Entrambi i metodi li ho provati e non sono affatto affidabili !!!
Il problema è che non gestiscono per niente l'accesso esclusivo alla 
risorsa per cui se in due eseguono contemporaneamente il codice e 
possibilissimo che leggano lo stesso numero.
Bisogna tenere presente che i tempi di esecuzione di una singola 
istruzione non sono deterministici per cui spesso a causa di rallentamenti 
su un PC (processi di sistema) un istruzione viene eseguita dopo un tot 
tempo...
In questo caso puo capitare che entrambi abbiano istanziato il doc 
(nell'es. Set doc=view.getfirstdocument) e il primo lo salva con nuovo valore il secondo lo salva con lo stesso 
valore dopo un tot tempo e non contemporaneamente !

sblocco ...io uso un gruppo ALL a cui appartengono tutti gli interessati.
Era prevedibile, direi... peccato che...
NON VALGA NIENTE.
Ma come? Prima mi fai tutto quel bel discorsino sull'incertezza per gli
accessi in tempi vicini e poi mi "risolvi" la situazione con un campo
reader?
E se uno apre il documento mentre tu lo stai editando e non hai impostato il
reader?
E se lo aprite QUASI (diff < 1 sec) contemporaneamente?
Te lo dice il tato che succede: CONFLITTO!
Chiedi, gentilmente, scusa a Paolo e fatti spiegare come funzionano i suoi
metodi, visto che non l'hai capito.
PS Caro Paolo, non so se sono il primo a trovare il "nuovo" metodo di lock,
ma credo di aver trovato un metodo per ridurre di 4 o 5 volte i tempi e la
complessità richiesti.

 BLA, BLA, BLA...
Ma te lo sei fatto spiegare da qualcuno che il metodo save di un doc ritorna
un boolean e che tale BOOL è false se hai impostato i PARMS a false, false e
qualcuno ha salvato prima di te?
Non per essere cattivo; ma questo è il metodo cumunemente usato da qualunque
consulente Domino per la produzione di numeri di protocollo.
Tanto per dirne una, è in produzione in direzione tecnica Autostrade con 400
utenti sopra è non ha mai creato un duplicato.

ha loccato può accedere al doc numero e aggiornarlo.
_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at 
http://www.hotmail.com
.
-- 
Posted from [212.131.129.131] by way of 
f300.law14.hotmail.com
 [64.4.20.175] 


...
Set view=db.getview("Prog_segn")   'vista contatore
Set doc=view.getfirstdocument ' il documento contatore
Do
  prog=doc.Prog_segn_mod(0)
  uidoc.document.Prog_segn = prog ' assegno il valore dove mi serve ....
  doc.Prog_segn_mod=prog + 1 ' aumento il contatore
Loop While Not doc.Save(False,False)   ' salvo solo quando nessuno sta
salvando.
Cazziatone (con una z?) anche a te ;-)
La GetFirstDocument deve essere la prima chiamata dopo il Do sennò non
funziona 'na mazza. :-P

Alla prossima...
Si basa anche la seconda sul save(false, false), salvo che invece di usare
un doc contatore esterno usi il doc corrente al fine di lockare esso stesso.

Ma la domanda piu' generica e?
Perche' dobbiamo snaturare il prodotto, per farne una copia dei
relazionali? Perche' non usare i DBMS "ordinari" invece di Notes per
fare quello che gia' gli altri fanno bene da moolto tempo?
Il Lock in Notes richiede :
a) che non esistano repliche del DB, 
sa' na' sega doc.Save (False, False) come controllare i documenti non
visibili.
b) Collegarsi da un client Notes e non Browser.
A quel punto cosa' c'e' rimasto di Notes? 
Ciao,
TL14!
------------
Se la fortuna e cieca,
la sfiga ci vede benissimo
e a volte piglia pure la mira
------------

Anche se ho postato contro questa filosofia di forzature in Notes.
Vi volevo segnalare che mi sono rapito il codice e che lo considero
moolto interessante.
Chissa prima o poi trovo qualche ASquattrocentista che mi obbliga a
farlo, IO INTANTO TENGO DURO!!


 consulente Domino per la produzione di numeri di protocollo.
Vero ho pestato la stessa merda anch'io, mi sono pentito dopo 5 minuti
ed ho fatto una funzione esterna (portabile multipiattaforma, anche su
AS/400) che chiede il protocollo via socket ad un 
add.in
 task di domino
preposto allo scopo. 
Non per essere cattivo, ma io dei metodi poco consistenti delle classi
di domino mi sarei un po' rotto le palle.
-- 
Dr. Ugo Gagliardelli, Modena, Italy
Spaccamaroni andate a cagare/Spammers not welcome


P.S. tutto questo funziona se il DB e' sul server (ovvio) ma se per
motivi miei, devo usare una replica  la cosa non funziona piu' cosi'
bene, sarei costretto a replicare solo la vista che esclude il documento
numeratore e comunque non funzionerebbe con il client scollegato.


>Entrambi i metodi li ho provati e non sono affatto affidabili !!!
come è già stato detto , Notes non è relazionale , eccetera eccetera , i
semafori , i lock ,  i socket ....
ma io con quelle 4 righe di script creo un milione di numeri di protocollo
all'anno alla regione lombardia settore sanità e non ne sbaglia nessuno.
ero
scettico anche io e non ho dormito per un paio di settimane , poi al
100.000
documento in cui tutto filava liscio mi sono addormentato. e il documento
contatore non solo sta su un db differente ,  ma anche su un server
differente.
ciao , e non litighiamo tra di noi! già tutti ci vogliono male...
-----
| Paolo Armando
| Programmatore Notes&Domino - Orgoglioso di esserlo!
| 03475091395
-----
-- 
Posted from [213.255.46.171] 


Se vuoi sto sviluppando una procedura di Lock per le Repliche.


la cosa mi interessa molto , puoi dirla qui?


 fare quello che gia' gli altri fanno bene da moolto tempo?
vero, ma il numero progressivo è un'esigenta talmente universale che bisogna
fornirla , altrimenti non si farebbero almeno la metà del database.

 Se vuoi sto sviluppando una procedura di Lock per le Repliche.
In che senso, che aggiorni il contatore su tutte le repliche che ci sono
in giro?
Allora dillo che sei un marziano!
:))




E' la prima cosa che ho pensato anche io......
Però funziona, in fondo il record da bloccare è sempre quello.
ADC


Secondo me perdiamo innumerevoli quantita' di tempo a riconvertire, o
a rimodernare (creargli un front-end piu' gradevole, o Web), i vecchi
programmi che funzionano bene nei DBMS relazionali, invece di creare
quello strato aggiuntivo di applicativi a qui e' indirizzato Notes.
Tutti quelli applicativi intenti a migliorare il lavoro di gruppo e
slegati da qualsiasi mezzo e luogo di accesso.
p.s.: Purtroppo TL14 si vede costretto a parlar bene e a razzolare
male, poiche' i money girano ancora sulla prima che ho detto.


in giro?
Non solo... posso aggiornare tutti i doc su tutte le repliche di un db.


Intravedo la possibilita', ma dev'essere un lavoro lungo e palloso.
Non dirmi che lo fa' anche velocemente.


Non dirmi che lo fa' anche velocemente.
Sui client solo una script library con l'oggetto NoteLock, quindi lo puoi
usare su qualsiasi client senza preinstallare e sul web. Sul server ci può
essere un DB che deve essere visibile real time da tutti quelli in replica e
puo avere solo codice notes per l'aggiornamento alla richiesta di lock o
schedulato; oppure una dll per l'aggiornamento real-time.
La cosa, al di là dei tempi di connessione è veloce, dato che si risolve in
un'UNICA operazione di salvataggio ed una cancellazione o modifica di un doc
in unlock.