/ Forside / Teknologi / Udvikling / ASP / Nyhedsindlæg
Login
Glemt dit kodeord?
Brugernavn

Kodeord


Reklame
Top 10 brugere
ASP
#NavnPoint
smorch 9259
Harlekin 1866
molokyle 1040
Steffanst.. 758
gandalf 657
smilly 564
gibson 560
cumano 530
MouseKeep.. 480
10  Random 410
Application.Lock
Fra : Jimmy


Dato : 26-03-03 11:09

Hej

I manualer/bøger kan man læse at application.lock forhindrer opdatering af
en application variabel fra to Sessioner på samme tid. Man kan først
opdatere application variablen når man har lavet en application.Unlock

Application.lock
Application("var1") = et eller andet
Application.Unlock

Mit spørgsmål er egentlig. hvad er det der sker?

Som jeg læser dette, så når du har lavet din Application.lock, så stopper
alle andre Sessioner ved Application.lock, hvis der allerede er en der har
sat locken. Ingen Sessioner kan gå videre i koden før at Application.Unlock
er blevet kørt af den Session der har locken. Hvis dette er rigtigt så burde
dette kunne lade sig gøre:

Application.lock
En masse kode bla. opdatering af databaser, while løkker m.m. Egentlig
behøver der ikke at blive tildelt en værdi til en Application variabel. Der
vil kun være en der kan udføre denne kode ad gangen
Application.Unlock

Har jeg ret i dette, eller er jeg fuldstændigt på vildspor?

Hvorfor jeg spørger er fordi at jeg har et lille problem med at flere kan
skrive i Databasen på samme tid, hvilket giver nogle forkerte beregninger.

Håber at der er nogen der kan hjælpe mig?

--


Jimmy



 
 
Chrisser (26-03-2003)
Kommentar
Fra : Chrisser


Dato : 26-03-03 13:51

"Jimmy" <pleasereplyingroup@hotmail.com> skrev i en meddelelse news:3e817bf4$0$31939$edfadb0f@dread12.news.tele.dk...
[snip]
> Application.lock
> En masse kode bla. opdatering af databaser, while løkker m.m. Egentlig
> behøver der ikke at blive tildelt en værdi til en Application variabel. Der
> vil kun være en der kan udføre denne kode ad gangen
> Application.Unlock
>
> Har jeg ret i dette, eller er jeg fuldstændigt på vildspor?
>
> Hvorfor jeg spørger er fordi at jeg har et lille problem med at flere kan
> skrive i Databasen på samme tid, hvilket giver nogle forkerte beregninger.
>

Jeg vil sige at du er på vildspor
Dine eventuelle Application variable hænger jo ikke sammen med adgangen til databasen, med mindre selvfølgelig at du bruger nogle Applicationvariable til åbning af database mm.

Under alle omstændigheder vil det bære nemmere, "renere" og sikkert mindre fejlbehæftet[*] at låse de tabeller du er ved at opdatere. Dette kan både gøres i selve sql'en og/eller ved hjælp af de parametre du putter på et recordset når du åbner det.

Det er dog ikke let at give dig "den bedste" løsning før vi ved hvordan du tilgår din database og hvordan du opdaterer dine tabeller.
Summa sumarum: Post lidt kode omkring en typisk opdatering af en tabel som du gør det nu, så er det lettere at komme med gode råd.

[*] Hermed mener jeg at hvis din idé virkede kunne du jo komme til at spærre for meget andet end databasetilgangen og det kunne, i yderste tilfælde, ende i kaos

Mvh
Christina

Jimmy (26-03-2003)
Kommentar
Fra : Jimmy


Dato : 26-03-03 15:45

[snip]
>> Application.lock
>> En masse kode bla. opdatering af databaser, while løkker m.m. Egentlig
>> behøver der ikke at blive tildelt en værdi til en Application variabel.
Der
>> vil kun være en der kan udføre denne kode ad gangen
>> Application.Unlock
>>
>> Har jeg ret i dette, eller er jeg fuldstændigt på vildspor?
>>
>> Hvorfor jeg spørger er fordi at jeg har et lille problem med at flere kan
>> skrive i Databasen på samme tid, hvilket giver nogle forkerte
beregninger.
>>

>Jeg vil sige at du er på vildspor

hehe... Det anede mig...

>Dine eventuelle Application variable hænger jo ikke sammen med adgangen til
databasen, med mindre selvfølgelig at du bruger nogle
>Applicationvariable til åbning af database mm.

Nej det kan jeg godt se, men tanken var at når siden mødte en
Application.lock, så ventede den ved den linie kode indtil der blev låst op
igen, ellers kan jeg ikke rigtigt se hvordan det egentlig fungerer, for hvis
den går videre alligevel, selv om der er en lock på, hvad ligger så til
grund for at man ikke kan skrive en ny værdi til en application variabel.
Det jeg så tænkte var at hvis den stoppede der, så kan du jo komme hvad som
helst imellem en lock og en unlock og så være sikker på at det ikke blev
kørt af mere end en session ad gangen.

>Under alle omstændigheder vil det bære nemmere, "renere" og sikkert mindre
fejlbehæftet[*] at låse de tabeller du er ved at opdatere. >Dette kan både
gøres i selve sql'en og/eller ved hjælp af de parametre du putter på et
recordset når du åbner det.

Ja, det har du ret i, men mit problem er at jeg hælder data i en temporær
tabel mange gange, og på et eller andet tidspunkt i slutningen af min kode
henter jeg alle data igen, regner lidt på det, og hælder det over i en anden
tabel. Problemet er sådan set ikke at der er flere der kan skrive i den
temporære tabel samtidigt, men mere at der er flere der kan nå at ligge data
i den inden at jeg får hentet dataene igen i en ny sql.

Derfor har jeg brug for at kunne låse hele kodestumpen, og ikke kun den
temporære tabel, som vist nok er låst sådan at kun en kan skrive til den ad
gangen i forvejen. :)

>Det er dog ikke let at give dig "den bedste" løsning før vi ved hvordan du
tilgår din database og hvordan du opdaterer dine tabeller.
>Summa sumarum: Post lidt kode omkring en typisk opdatering af en tabel som
du gør det nu, så er det lettere at komme med gode råd. >

Ja, det har jeg så ikke gjort i denne omgang, men det kan jo være senere :)
, men problemstillingen er lidt sådan her:

1. While
2. Skriv data til temporær tabel
3. wend
4. mere kode
5. Hent data fra temporær tabel
6. regne lidt på data
7. Smid data ned i endelig tabel

Problemet er her at jeg gerne vil låse fra og med linie 1 til og med linie
5, således at jeg er sikker på at det jeg henter fra den temporære tabel kun
er data fra en Session og ikke flere. Jeg ved at jeg bare kan gemme Session
id et med i den temporære tabel, men det må da kunne lade sig gøre på denne
her måde også ikke, eller...???

>[*] Hermed mener jeg at hvis din idé virkede kunne du jo komme til at
spærre for meget andet end databasetilgangen og det kunne, i >yderste
tilfælde, ende i kaos

Men ikke desto mindre er det det jeg gerne vil. Altså ikke lave kaos, men
låse for meget mere end database tilgangen. ;)

>Mvh
>Christina

Tak for hjælpen indtil videre, håber at der kommer lidt mere, hehe... ;)



Chrisser (27-03-2003)
Kommentar
Fra : Chrisser


Dato : 27-03-03 08:15

"Jimmy" <pleasereplyingroup@hotmail.com> skrev i en meddelelse news:3e81bc9c$0$31973$edfadb0f@dread12.news.tele.dk...
[snip]

> Nej det kan jeg godt se, men tanken var at når siden mødte en
> Application.lock, så ventede den ved den linie kode indtil der blev låst op
> igen, ellers kan jeg ikke rigtigt se hvordan det egentlig fungerer, for hvis
> den går videre alligevel, selv om der er en lock på, hvad ligger så til
> grund for at man ikke kan skrive en ny værdi til en application variabel.
> Det jeg så tænkte var at hvis den stoppede der, så kan du jo komme hvad som
> helst imellem en lock og en unlock og så være sikker på at det ikke blev
> kørt af mere end en session ad gangen.

Det er ikke sådan at "verden fryser fast" når du laver en Application.Lock. Låsen sættes kun på eventuelle Application variable for at hindre data korruption. Du kan sammenligne det med at låse en enkelt tabel - det hindrer jo heller ikke opdatering af andre tabeller i mellemtiden - kun den du har låst. Så rent praktisk vil jeg mene at din kode fortsætter ufortrødent med mindre du altså forsøger en opdatering af en Application variabel....

[snip]

> 1. While
> 2. Skriv data til temporær tabel
> 3. wend
> 4. mere kode
> 5. Hent data fra temporær tabel
> 6. regne lidt på data
> 7. Smid data ned i endelig tabel
>
> Problemet er her at jeg gerne vil låse fra og med linie 1 til og med linie
> 5, således at jeg er sikker på at det jeg henter fra den temporære tabel kun
> er data fra en Session og ikke flere. Jeg ved at jeg bare kan gemme Session
> id et med i den temporære tabel, men det må da kunne lade sig gøre på denne
> her måde også ikke, eller...???

Jeg synes en reneste (og bedste ) måde vil være at kunne indentificere de data du har hældt i den temporere tabel. Jeg er ikke helt klar over om ASP levner dig mulighed for at låse et stykke kode, jeg har aldrig haft brug for at undersøge det, men hvis du har mange brugere ville det jo også kunne resultere i unødig ventetid for brugeren. Så jeg synes stadig den anden idé er bedre

> Tak for hjælpen indtil videre, håber at der kommer lidt mere, hehe... ;)

Det kom i hvert fald et par betragtninger

Chrisser

Jimmy (27-03-2003)
Kommentar
Fra : Jimmy


Dato : 27-03-03 08:32

>Det er ikke sådan at "verden fryser fast" når du laver en Application.Lock.
Låsen sættes kun på eventuelle Application variable for at >hindre data
korruption. Du kan sammenligne det med at låse en enkelt tabel - det hindrer
jo heller ikke opdatering af andre tabeller i >mellemtiden - kun den du har
låst. Så rent praktisk vil jeg mene at din kode fortsætter ufortrødent med
mindre du altså forsøger en >opdatering af en Application variabel....

Aha, så jeg kunne i virkeligheden sætte linie 0 og linien efter samt 8 ind i
min kode:

0. Application.Lock
Application("dummy") = 1
1. While
2. Skriv data til temporær tabel
3. wend
4. mere kode
5. Hent data fra temporær tabel
6. regne lidt på data
7. Smid data ned i endelig tabel
8. Application.Unlock

Så ville jeg opnå det jeg vil, hehe... :)

> 1. While
> 2. Skriv data til temporær tabel
> 3. wend
> 4. mere kode
> 5. Hent data fra temporær tabel
> 6. regne lidt på data
> 7. Smid data ned i endelig tabel

>Jeg synes en reneste (og bedste ) måde vil være at kunne indentificere de
data du har hældt i den temporere tabel. Jeg er ikke helt klar >over om ASP
levner dig mulighed for at låse et stykke kode, jeg har aldrig haft brug for
at undersøge det, men hvis du har mange >brugere ville det jo også kunne
resultere i unødig ventetid for brugeren. Så jeg synes stadig den anden idé
er bedre

Jeg tror du har ret, og jeg har prøvet at teste de 10 linier kode jeg lige
har lagt ind i denne post, og det lader ikke til at virke helt efter
hensigten, eller også gør jeg bare et eller andet forkert.

Nå, men jeg vælger nu at tage imod dit råd, så jeg gemmer et sessionID med i
den temporære tabel, og bruger det samme sessionID, når jeg henter data
igen, så burde det kun være de rigtige data for den pågældende ene session
der bliver vist.

>> Tak for hjælpen indtil videre, håber at der kommer lidt mere, hehe... ;)

>Det kom i hvert fald et par betragtninger

Det var dejligt ;)

Jimmy



Jesper Nielsen (28-03-2003)
Kommentar
Fra : Jesper Nielsen


Dato : 28-03-03 08:28

> Nå, men jeg vælger nu at tage imod dit råd, så jeg gemmer et sessionID med
i
> den temporære tabel, og bruger det samme sessionID, når jeg henter data
> igen, så burde det kun være de rigtige data for den pågældende ene session
> der bliver vist.

Pas på med det - SessionIDs er ikke unikke over tid.

--
Mvh. Jesper



Chrisser (28-03-2003)
Kommentar
Fra : Chrisser


Dato : 28-03-03 08:36

"Jesper Nielsen" <jn@nielsenit.dk> skrev i en meddelelse news:FPSga.1256$mI2.254818@news000.worldonline.dk...
> > Nå, men jeg vælger nu at tage imod dit råd, så jeg gemmer et sessionID med
> i
> > den temporære tabel, og bruger det samme sessionID, når jeg henter data
> > igen, så burde det kun være de rigtige data for den pågældende ene session
> > der bliver vist.
>
> Pas på med det - SessionIDs er ikke unikke over tid.

Men de er unikke i samme session [*], og hvis den bare skal bruges i et stykke kode på en og samme side kombineret med lidt database tilgang, så vil jeg synes at det er OK.
Sessions bruges jo til at identificere en bruger mens han er "på", og der går da meget godt det meste af tiden...

[*]
Så vidt jeg da ved af - ellers kan man jo blot oprette sin egen session på brugeren med en eller anden unik indetifier.


Chrisser

Jimmy (28-03-2003)
Kommentar
Fra : Jimmy


Dato : 28-03-03 11:57

Ja, i har begge ret, hehe...

--


Jimmy

"Chrisser" <cbj@egdatainform.dk> skrev i en meddelelse
news:b60u49$ivl$1@sunsite.dk...
"Jesper Nielsen" <jn@nielsenit.dk> skrev i en meddelelse
news:FPSga.1256$mI2.254818@news000.worldonline.dk...
> > Nå, men jeg vælger nu at tage imod dit råd, så jeg gemmer et sessionID
med
> i
> > den temporære tabel, og bruger det samme sessionID, når jeg henter data
> > igen, så burde det kun være de rigtige data for den pågældende ene
session
> > der bliver vist.
>
> Pas på med det - SessionIDs er ikke unikke over tid.

Men de er unikke i samme session [*], og hvis den bare skal bruges i et
stykke kode på en og samme side kombineret med lidt database tilgang, så vil
jeg synes at det er OK.
Sessions bruges jo til at identificere en bruger mens han er "på", og der
går da meget godt det meste af tiden...

[*]
Så vidt jeg da ved af - ellers kan man jo blot oprette sin egen session på
brugeren med en eller anden unik indetifier.


Chrisser



Søg
Reklame
Statistik
Spørgsmål : 177552
Tips : 31968
Nyheder : 719565
Indlæg : 6408849
Brugere : 218887

Månedens bedste
Årets bedste
Sidste års bedste