[ASP.NET 2.0] ViewState gedeeld tussen sessies?

[--MeAngry--]

Aangezien ik altijd PHP developer ben geweest heeft ASP.NET mij al vrij vaak achter de oren doen krabben door de totaal andere manier van werken. (OOP daargelaten.) Maar hier kom ik dus echt even niet uit. Ik doe ergens iets grandioos verkeerd, maar na het lezen van diverse artikelen over dit onderwerp ben ik niets wijzer over het hoe en wat van de ViewState.

De situatie:
Een GridView met daarin een heleboel records, voor het gemak personen. Al de rijen zijn voorzien van CommandFields met een View, Edit en Delete knop.
Als de gebruiker op de Editknop klikt bijvoorbeeld, dan wordt deze actie opgevangen door het RowCommand event en wordt de selectedIndex in een sessievariabele gezet, en de gebruiker doorgestuurd naar een andere pagina, Edit.aspx. Hier worden de gegevens van die persoon opgehaald en in een formulier gezet om te kunnen bewerken.

Het initiële probleem:
Er werken nogal wat gebruikers tegelijkertijd met die applicatie en het volgende kan dus voorkomen:

1. Gebruiker A roept overzicht personen op
2. Gebruiker B voegt een nieuw persoon toe (die wordt dus aan het overzicht toegevoegd)
3. Gebruiker A klikt op Edit bij een bepaalde persoon (zonder de pagina te refreshen)
4. Gebruiker A krijgt een heel andere persoon in Edit.aspx te zien omdat de volgorde van gebruikers in het grid is veranderd zonder dat hij het heeft gemerkt.

De selectedIndex waarde klopt dus niet meer als er in de tussentijd een extra persoon wordt toegevoegd.

De initiële oplossing:
Geen gebruik maken van het RowCommand event met selectedIndex, maar op de Editknop een onClientClick javascriptje hangen die verwijst naar Edit.aspx met daarin de ID van de persoon in de QueryString.

An sich werkte dit goed, ook al kon ik niet goed begrijpen waarom dat de initiële functionaliteit niet goed werkte. Zou dat standaard echt zo slecht werken met meerdere gebruikers?
De problemen bleken hier echter niet mee opgelost te zijn.

Het huidige nieuwe probleem:

1. Gebruiker A komt op Edit.aspx en gaat aan de slag met de persoonsgegevens.
2. Gebruiker B klikt een andere persoon aan en gaat deze bewerken op de Edit.aspx pagina.
3. Gebruiker A klikt op een knop die een PostBack veroorzaakt en kijkt nu in plaats van naar zijn eigen persoonsgegevens, naar de persoonsgegevens van Gebruiker B!
   Oftewel, alle veldwaardes zijn vervangen door die van de persoon waar Gebruiker B op heeft geklikt.

Vervolgens ben ik dus gaan zoeken naar een fatsoenlijke oplossing, want ook hier kan ik wel weer een quickfix voor gaan implementeren op een of andere ranzige manier, maar dan krijg ik die problemen nog veel vaker ben ik bang.

Aangezien ik nog niet erg lang met ASP.NET (in C# overigens) werk zal ik wel iets totaal over het hoofd zien, maar op het moment lijkt het er voor mij op dat de ViewState gedeeld is tussen meerdere gebruikerssessies. Iets waar ik met m'n hoofd niet bij kan, want dit is echt een security issue van de hoogste plank, en het brengt (zoals je merkt) erg veel ongewenste 'functionaliteit' mee.

Wat ik dus al heb geprobeerd is de ViewState volledig uitschakelen (in de Web.Config), maar dit heeft niets geholpen, er gebeurt nog steeds hetzelfde.
Daarnaast heb ik artikelen gevonden waarin wordt uitgelegd hoe ik zelf kan zorgen dat de ViewState op een andere manier wordt opgehaald en opgeslagen, maar ik weet dus niet eens zeker of mijn probleem hier überhaupt wel ligt, aangezien ik op sommige plekken ook weer lees dat de ViewState juist niet persé zorgt voor het bewaren van gegevens in bijvoorbeeld tekstvelden.

Ik wil dus juist voorkomen dat er iets gedeeld wordt tussen verschillende sessies! Iedereen moet in zijn of haar eigen sessie met de globale lijst van personen kunnen werken en niet ineens de persoon van een ander in beeld krijgen tijdens het bewerken van een persoon.

Sorry voor de n00bvraag wellicht, maar ik hoop dat ik mijn problemen duidelijk genoeg heb uiteengezet zodat iemand mij hiermee zou kunnen helpen, of in ieder geval even mee kan kijken.

[ Voor 3% gewijzigd door --MeAngry-- op 26-02-2008 12:45 ]

[ESTANNY]

Ik denk niet dat je ViewStates kan sharen tussen verschillende sessies, (shoot me if you can).

Misschien kan je ipv de selected index bij te houden, met de ID werken. Let eens op de AccessKey.

Ik heb gridview's zelf nog niet gebruikt, maar wel datalist en detailsview. Zo kan je AccessKey="ID" die overeenkomt met de ID van de database.
Een ander ding dat je kan doen is jou buttons voorzien van een clientscript waar je de ID meestuurt. Die plaats je dan in een hiddenfield die dan weer beschikbaar is in de codebehind.

[jan-marten]

Ik heb hetzelfde probleem ongeveer gehad. Had een ASP.NET project in VB gemaakt waarbij een bepaalde variable op module niveau bewaard werd. Wat blijkt nu, die variabele blijft bestaan tussen de verschillende aanroepen van verschillende clients. De pagina fungeert dus als een ASP.NET applicatie die dus ook constant blijft draaien en waarin die globale var's ook onthouden worden.

offtopic:
Global.asax is ook erg handig, hierin zitten opstart en afsluit functies voor het gehele project maar dat is offtopic.

In plaats van een GridView maak ik trouwens liever gebruik van een repeater omdat je dan wat meer controle hebt over de opmaak en de toeters en bellen achter de knoppen.

[--MeAngry--]

ESTANNY schreef op dinsdag 26 februari 2008 @ 12:17:
Ik denk niet dat je ViewStates kan sharen tussen verschillende sessies, (shoot me if you can).

Misschien kan je ipv de selected index bij te houden, met de ID werken. Let eens op de AccessKey.

Ik heb gridview's zelf nog niet gebruikt, maar wel datalist en detailsview. Zo kan je AccessKey="ID" die overeenkomt met de ID van de database.
Een ander ding dat je kan doen is jou buttons voorzien van een clientscript waar je de ID meestuurt. Die plaats je dan in een hiddenfield die dan weer beschikbaar is in de codebehind.

Dat is wat ik nu dus heb gedaan, maar het is geen complete oplossing.

Ik wil namelijk juist niet hebben dat de ViewState tussen verschillende sessies gedeeld is. Iedereen moet een gewoon een persoon kunnen bewerken, tegelijkertijd, zonder dat ze het risico lopen per ongeluk de verkeerde te zien te krijgen.

[sig69]

--MeAngry-- schreef op dinsdag 26 februari 2008 @ 12:07:
...
Het initiële probleem:
Er werken nogal wat gebruikers tegelijkertijd met die applicatie en het volgende kan dus voorkomen:

1. Gebruiker A roept overzicht personen op
2. Gebruiker B voegt een nieuw persoon toe (die wordt dus aan het overzicht toegevoegd)
3. Gebruiker A klikt op Edit bij een bepaalde persoon (zonder de pagina te refreshen)
4. Gebruiker A krijgt een heel andere persoon in Edit.aspx te zien omdat de volgorde van gebruikers in het grid is veranderd zonder dat hij het heeft gemerkt.

De selectedIndex waarde klopt dus niet meer als er in de tussentijd een extra persoon wordt toegevoegd.

Logisch.

De initiële oplossing:
Geen gebruik maken van het RowCommand event met selectedIndex, maar op de Editknop een onClientClick javascriptje hangen die verwijst naar Edit.aspx met daarin de ID van de persoon in de QueryString.

Je idee om de ID van de persoon te gebruiken is goed, al snap ik niet waarom je daar javascript voor nodig zou hebben?
Waarom niet:

code:

<asp:HyperLinkField DataNavigateUrlFields="Id" DataNavigateUrlFormatString="Edit.aspx?id={0}" Text="Edit" />

An sich werkte dit goed, ook al kon ik niet goed begrijpen waarom dat de initiële functionaliteit niet
goed werkte. Zou dat standaard echt zo slecht werken met meerdere gebruikers?

Als je in een multi-user omgeving met row-indices gaat werken kan je dit soort dingen verwachten inderdaad.

De problemen bleken hier echter niet mee opgelost te zijn.

Het huidige nieuwe probleem:

1. Gebruiker A komt op Edit.aspx en gaat aan de slag met de persoonsgegevens.
2. Gebruiker B klikt een andere persoon aan en gaat deze bewerken op de Edit.aspx pagina.
3. Gebruiker A klikt op een knop die een PostBack veroorzaakt en kijkt nu in plaats van naar zijn eigen persoonsgegevens, naar de persoonsgegevens van Gebruiker B!
   Oftewel, alle veldwaardes zijn vervangen door die van de persoon waar Gebruiker B op heeft geklikt.

Hoe dit kan weet ik niet, het lijkt erop dat de id op applicatie-niveau ergens bewaard wordt ipv op sessie niveau. Ik denk dat je hier even wat (relevante) code voor moet posten.

[ Voor 3% gewijzigd door sig69 op 26-02-2008 13:23 ]

[--MeAngry--]

sig69 schreef op dinsdag 26 februari 2008 @ 12:52:
[...]

Logisch.

Ik vind dat niet logisch als PHP programmeur.
Ik kijk naar een pagina met 5 rijen data, ik klik de middelste rij aan, dan verwacht ik op index 2 (vanaf 0 tellen) te klikken. Wat is anders sowieso het nut van zo'n ding, als je totaal niet weet op welke index je nu eigenlijk gaat klikken? Dat slaat gewoon kant noch wal.

[...]

Je idee om de ID van de persoon te gebruiken is goed, al snap ik niet waarom je daar javascript voor nodig zou hebben?

Omdat ik hier middels een Eval() gewoon de vaste waarde van het ID in kon zetten. Als ik de ID in het CommandArgument meegeef klopt deze ook niet altijd met de rij (en de persoon dus) waar ik op klik. En dat is gewoon onlogisch.

[...]

Als je in een multi-user omgeving met row-indices gaat werken kan je dit soort dingen verwachten inderdaad.

Nou, moooie prutserobjecten dan

[...]

Hoe dit kan weet ik niet, het lijkt erop dat de id op applicatie-niveau ergens bewaard wordt ipv op sessie niveau. Ik denk dat je hier even wat (relevante) code voor moet posten.

En hier ligt mijn voornaamste probleem denk ik, alleen heb ik geen idee waar het door komt.

[ Voor 3% gewijzigd door --MeAngry-- op 26-02-2008 13:23 ]

[Cloud]

--MeAngry-- schreef op dinsdag 26 februari 2008 @ 13:22:
Ik vind dat niet logisch als PHP programmeur.
Ik kijk naar een pagina met 5 rijen data, ik klik de middelste rij aan, dan verwacht ik op index 2 (vanaf 0 tellen) te klikken. Wat is anders sowieso het nut van zo'n ding, als je totaal niet weet op welke index je nu eigenlijk gaat klikken? Dat slaat gewoon kant noch wal.

Volgens mij gebruik je rowindices gewoon compleet verkeerd. Een rowindex kun je alleen gebruiken op de huidige set data. Je moet niet alvorens het ID op te zoeken via de rowindex de grid gaan verversen natuurlijk, dan is het logisch dat je rowindex niet meer klopt met jouw data. En dat is feitelijk wat je nu doet, al is dat dan op een andere pagina.

Je moet de primaire sleutel van het record dat je nodig hebt doorgeven via de Sessie. En niets anders. Rowindices (van een grid) doorgeven is hoe dan ook fout.

[sig69]

--MeAngry-- schreef op dinsdag 26 februari 2008 @ 13:22:
[...]

Ik vind dat niet logisch als PHP programmeur.
Ik kijk naar een pagina met 5 rijen data, ik klik de middelste rij aan, dan verwacht ik op index 2 (vanaf 0 tellen) te klikken. Wat is anders sowieso het nut van zo'n ding, als je totaal niet weet op welke index je nu eigenlijk gaat klikken? Dat slaat gewoon kant noch wal.

Sorry hoor, ik kan me niet voorstellen dat PHP automatisch detecteert dat er een nieuw record is aangemaakt en dan de geselecteerde index "mapt" naar een andere. Index 10 is en blijft index 10, en als er een record daarvoor toegevoegd wordt is index 10 dus gewoon een ander record dan je selecteerde. Index 11 zou dan dus wel de goede moeten zijn, maar zie dat maar eens te detecteren. Daarom moet je ook met Id's van het record werken en niet met een index uit een lijst.

[...]

Omdat ik hier middels een Eval() gewoon de vaste waarde van het ID in kon zetten.

Zie mijn edit boven, is iets netter.

Als ik de ID in het CommandArgument meegeef klopt deze ook niet altijd met de rij (en de persoon dus) waar ik op klik. En dat is gewoon onlogisch.

Mee eens. Ik neem aan dat er ergens anders iets fout gaat maar als je geen code post komen we daar nooit achter.

[...]
Nou, moooie prutserobjecten dan

De objecten zijn prima, je gebruikt ze alleen verkeerd

[--MeAngry--]

wolkje schreef op dinsdag 26 februari 2008 @ 13:32:
[...]

Volgens mij gebruik je rowindices gewoon compleet verkeerd. Een rowindex kun je alleen gebruiken op de huidige set data.

Dat is ook wat ik wil doen.

Je moet niet alvorens het ID op te zoeken via de rowindex de grid gaan verversen natuurlijk, dan is het logisch dat je rowindex niet meer klopt met jouw data. En dat is feitelijk wat je nu doet, al is dat dan op een andere pagina.

Waar doe ik dat dan? Ik heb het gridView voor m'n neus, klik op de Editknop, en in het RowCommand Event ga ik adhv de selectedIndex of ID die ik heb meegekregen naar een volgende pagina. Voordat ik echter naar de volgende pagina schiet sla ik deze index of ID echter op in een sessie. En toch klopt de waarde daar al niet.

Je moet de primaire sleutel van het record dat je nodig hebt doorgeven via de Sessie. En niets anders. Rowindices (van een grid) doorgeven is hoe dan ook fout.

Precies wat ik probeer te doen dus.

Over de GridView heb ik op MSDN nu trouwens wat extra info gevonden. Blijkbaar maken je instellingen (als ViewState en AutoPostBack) nogal wat uit als het gaat om concurrent werken, dus daar ga ik verder mee stoeien.
Wat ik me wel afvraag is waarom dit fout gaat:

_{Code van Edit.aspx}

C#:

protected void Page_Load(object sender, EventArgs e)
{
    if (Request.QueryString["PersonId"] == null && Session["EditPerson"] == null)
        Response.Redirect("~/Current.aspx", true);

    curPerson = Request.QueryString["PersonId"] == null ? (Trip)Session["EditPerson"] : PersonData.GetPersonById(Int32.Parse(Request.QueryString["PersonId"]));
    if (curPerson == null)
        Response.Redirect("~/Current.aspx", true);

    Session.Remove("EditPerson");
    Session.Add("EditPerson", curPerson);

    if (Page.IsPostBack) return;

    /* Hier worden de waardes van de formvelden ingevuld. */
}

Als ik de pagina als eerste binnenkom met ID = 1, dan krijg ik in de formuliervelden netjes de waardes van het object met ID = 1. Wanneer er nu een PostBack optreedt, door bijvoorbeeld het veranderen van selectList) en een andere gebruiker heeft ondertussen (op een andere PC) een ander object met ID = 2 aangeklikt, dan krijg ik nu ineens ook de waardes van object met ID = 2 in m'n velden te zien.

Dit terwijl de waarde m'n Sessievariabele wel degelijk klopt. ASP.NET vult de velden dus zelf in met de waarden van de andere gebruiker.

[ Voor 40% gewijzigd door --MeAngry-- op 26-02-2008 13:45 ]

[TeeDee]

Is de Index/Id toevallig 0 of 1? Misschien gaat het fout met een !IsPostback

Dus: toon eens wat code.

[ Voor 15% gewijzigd door TeeDee op 26-02-2008 13:38 ]

[Cloud]

--MeAngry-- schreef op dinsdag 26 februari 2008 @ 13:36:
Dat is ook wat ik wil doen.

Wat je dus moet doen, is bij het drukken op de Edit-button, de werkelijke ID van het record ophalen en opslaan in je sessie, vóórdat je navigeert naar een andere aspx-pagina. Je moet natuurlijk wel op de achtergrond (of desgewenst voorgrond) de primaire sleutel meenemen, zoals deze in de database bestaat. Anders kun je hem niet ophalen op het moment van een click.

Waar doe ik dat dan? Ik heb het gridView voor m'n neus, klik op de Editknop, en in het RowCommand Event ga ik adhv de selectedIndex of ID die ik heb meegekregen naar een volgende pagina. Voordat ik echter naar de volgende pagina schiet sla ik deze index of ID echter op in een sessie. En toch klopt de waarde daar al niet.

De waarde klopt prima, alleen je data is veranderd.

Precies wat ik probeer te doen dus.

Maar je SelectedIndex is niet per definitie de unieke sleutel van het record, waarmee je deze op elk gewenst moment terug kan vinden. En juist díe sleutel heb je nodig.

edit:

Kijk ook eens bij het voorbeeld van een ButtonField op MSDN.

[ Voor 6% gewijzigd door Cloud op 26-02-2008 13:46 ]

[sig69]

--MeAngry-- schreef op dinsdag 26 februari 2008 @ 13:36:
Waar doe ik dat dan? Ik heb het gridView voor m'n neus, klik op de Editknop, en in het RowCommand Event ga ik adhv de selectedIndex of ID die ik heb meegekregen naar een volgende pagina.

Waar komt het record dat je wilt bewerken op die pagina dan vandaan? Als je die ergens uit ophaalt adv de index, en de onderliggende datasource is veranderd, dan is dat toch logisch dat het niet klopt? Als je het ID gebruikt zou dat niet uit mogen maken.

Voordat ik echter naar de volgende pagina schiet sla ik deze index of ID echter op in een sessie. En toch klopt de waarde daar al niet.

De ID die je op de volgende pagina krijgt klopt niet bedoel je?

Edit:
Ik ga er overigens gemakshalve even vanuit dat de ID de PK is, dus waar ik het over een ID heb bedoel ik ook PK.

[ Voor 7% gewijzigd door sig69 op 26-02-2008 13:46 ]

[Remco]

Kan je eens wat code posten waarin je je sessie variabele set ?

[--MeAngry--]

sig69 schreef op dinsdag 26 februari 2008 @ 13:44:
[...]

Waar komt het record dat je wilt bewerken op die pagina dan vandaan? Als je die ergens uit ophaalt adv de index, en de onderliggende datasource is veranderd, dan is dat toch logisch dat het niet klopt? Als je het ID gebruikt zou dat niet uit mogen maken.

[...]

De ID die je op de volgende pagina krijgt klopt niet bedoel je?

Edit:
Ik ga er overigens gemakshalve even vanuit dat de ID de PK is, dus waar ik het over een ID heb bedoel ik ook PK.

Ten eerste allen al bedankt voor de hulp. We komen er wel uit, ik moet gewoon ergens een denkfout maken of iets fout hebben staan.

Ik zal even precies proberen te definiëren wat ik doe.
Dit is hoe het nu werkt in Currrent.aspx (de pagina met het GridView):

C#:

<asp:GridView ID="GridView" runat="server" DataKeyNames="PersonId">
    <Columns>
        <asp:TemplateField ShowHeader="False">
            <ItemTemplate>
                <asp:Button ID="btnView" runat="server" CausesValidation="False" PostBackUrl="<%# Eval(&quot;PersonId&quot;, &quot;~/Edit.aspx?ViewTrip=1&PersonId={0}&quot;) %>" Text="View" />
                <asp:Button ID="btnEdit" runat="server" CausesValidation="False" PostBackUrl="<%# Eval(&quot;PersonId&quot;, &quot;~/Edit.aspx?ViewTrip=0&PersonId={0}&quot;) %>" Text="Edit" />
                <asp:Button ID="btnDelete" runat="server" CausesValidation="False" PostBackUrl="<%# Eval(&quot;PersonId&quot;, &quot;~/Current.aspx?DeletePersonId={0}&quot;) %>" Text="Delete" />
            </ItemTemplate>
        </asp:TemplateField>
    </Columns>
</asp:GridView>

Dit is hoe het niet werkt, maar wel zou moeten werken volgens mij:

C#:

<asp:GridView ID="GridView" runat="server" DataKeyNames="PersonId">
    <Columns>
        <asp:TemplateField ShowHeader="False">
            <ItemTemplate>
                <asp:Button ID="btnView" runat="server" CausesValidation="False" CommandName="View" CommandArgument="PersonId" Text="View" />
                <asp:Button ID="btnEdit" runat="server" CausesValidation="False" CommandName="Edit" CommandArgument="PersonId" Text="Edit" />
                <asp:Button ID="btnDelete" runat="server" CausesValidation="False" CommandName="Delete" CommandArgument="PersonId" Text="Delete" />
            </ItemTemplate>
        </asp:TemplateField>
    </Columns>
</asp:GridView>

De code voor RowCommand:

C#:

protected void GridView_RowCommand(object sender, GridViewCommandEventArgs e)
{
    switch (e.CommandName)
    {
        case "Edit":
            Session.Remove("PersonId");
            Session.Add("PersonId", Int32.Parse(e.CommandArgument));
            Response.Redirect("Edit.aspx", true);
            break;
    }
}

[ Voor 6% gewijzigd door --MeAngry-- op 26-02-2008 13:57 ]

[sig69]

Is "PersonData.GetPersonById" een static method? Zet deze niet stiekem wat variabelen ergens, die hergebruikt worden?

[--MeAngry--]

sig69 schreef op dinsdag 26 februari 2008 @ 13:56:
Is "PersonData.GetPersonById" een static method? Zet deze niet stiekem wat variabelen ergens, die hergebruikt worden?

Die methode is static ja, maar er wordt een Sql query in uitgevoerd, elke keer opnieuw als die functie wordt aangeroepen. De resultaten daarvan worden direct teruggegeven uit de functie als Person.

[Cloud]

--MeAngry-- schreef op dinsdag 26 februari 2008 @ 13:52:
Dit is hoe het niet werkt, maar wel zou moeten werken volgens mij:

C#:

...

De code voor RowCommand:

C#:

...

Dit moet gewoon werken. Dit is namelijk precies wat ik voorstel Ik dacht dat je met een rowindex werkte, maar je werkt gewoon met het PKID uit de database zo te zien. Of is PersonID niet de unieke sleutel in je Persons database tabel?

Het gaat dus ergens anders mis. Misschien op je Edit pagina?

[sig69]

Ik zou "PersonData.GetPersonById" toch graag even willen zien...

[--MeAngry--]

Ik ben op dit moment m'n Grid even helemaal opnieuw aan het opzetten, want misschien heb ik voorheen gewoon ergens iets verkeerd gedaan waar ik nu al 5 keer overheen aan het kijken ben.

Het lijkt me in ieder geval verstandig voor mezelf, om dit even eerst te tacklen, zodat ik zeker weet dat ik in ieder geval de goede waarde op de Edit pagina heb.
Of er daar iets fout gaat kan ik dan tenminste daarna goed bekijken.

[Niemand_Anders]

Oplossing is simpel. Optimistic updates. ADO.NET breid dan automatisch de where clausule uit met de velden en hun oorspronkelijke waarden. Als het record tussentijds is gewijzigd zullen er geen records worden geupdate (where matched niet meer) en ado.net zal een DBConcurrencyException raisen.

Maar ado.net houd standaard al de concurrency mode aan als je gebruik maakt vai de DataAdaptor en DataSet. Concurrency updates werken natuurlijk niet als je zelf updates gaat brouwen.

Maar misschien is Linq to SQL iets wat meer in je straatje past. Visual Studio Express 2008 is gratis te downloaden van de MSDN website en daarmee kun je heerlijk aan de slag. Voor een aantal; zeer goede tutorials verwijs ik je naar de website van Scott Gutrie en dan met name de sectie 'Linq en .NET 3.5' en naar de ASP.NET LINQ videos.

Hoewel officieel nog in beta (CTP) is het ook verstandig eens een kijkje te nemen naar ASP.NET 3.5 Extentions update.

p.s. Als je Visual studio download, vergeet dan ook niet meteen de MSDN library te downloaden (2,2 GB download) zodat je een goede reference lokaal hebt. De MSDN library bevat ook een aantal handleidingen en korte tutorials.

[? ?]

..

[ Voor 104% gewijzigd door ? ? op 25-01-2013 09:52 ]

[Hydra]

--MeAngry-- schreef op dinsdag 26 februari 2008 @ 13:57:
Die methode is static ja, maar er wordt een Sql query in uitgevoerd, elke keer opnieuw als die functie wordt aangeroepen. De resultaten daarvan worden direct teruggegeven uit de functie als Person.

Je weet dat een functie niet atomic is? Als je niks aan synchronisatie doet kan ik me zo helemaal voorstellen dat hier iets misgaat.

era.zer schreef op dinsdag 26 februari 2008 @ 16:19:
Misschien een hulp, misschien niet (niet zo op de hoogte van viewstates).
Maar aangezien het misschien een sessie issue is:
Wij hadden hetvolgende probleem:
persoon A logt in, sessie wordt aangemaakt
persoon B logt in, sessie voor hem wordt aangemaakt
persoon A doet wat, en zit opeens met sessie van persoon B

Oorzaak:
In de IIS config van de application pool stond het "aantal werkprocessen" op 2 (default 1) en de sessies werden door elkaar gemixt.
Pentium 4 met HyperThreading die dacht (?) over 2 cpu's te beschikken en daarom stond dat default op 2 tijdens de installatie (? wie weet).

Sorry maar sessies hebben weinig te maken met het aantal workerthreads. Ook jouw probleem lijkt gewoon een kwestie van niet snappen dat je in asp.net opeens werkt met multhithreaded applicaties.

[ Voor 50% gewijzigd door Hydra op 26-02-2008 16:48 ]

[? ?]

..

[ Voor 108% gewijzigd door ? ? op 25-01-2013 09:52 ]

[Hydra]

era.zer schreef op woensdag 27 februari 2008 @ 10:29:
_{@Hydra en toch ging alles perfect nadat het workproces op 1 gesteld werd...
Zoals ik zei: ik ben niet op de hoogte van sessies e.d. in asp.net, maar dat was de uitleg van de asp.net programmeur en meer heeft hij ook niet veranderd. 't Kon misschien een hulp zijn voor de TS}

Die programmeur zou ik ontslaan. Hij heeft namelijk het symptoom bestreden, maar niet het probleem opgelost. Als je ervoor zorgt dat er maar 1 request per keer afgehandeld kan worden is het logisch dat je geen concurrency problemen krijgt.

[Verwijderd]

Waarom gebruik je eigenlijk een Sessie om je Id door te geven aan Edit.aspx ?

Je kunt toch gewoon Response.Redirect("Edit.aspx?Id=123") doen ??

[Cloud]

Verwijderd schreef op woensdag 27 februari 2008 @ 14:49:
Waarom gebruik je eigenlijk een Sessie om je Id door te geven aan Edit.aspx ?

Je kunt toch gewoon Response.Redirect("Edit.aspx?Id=123") doen ??

Dat brengt allerlei interessante veiligheidsrisico's met zich mee, waar je wel goed over na moet denken. Want wát als ik de url even verander naar: "Edit.aspx?Id=345"?

Dat neemt niet weg dat het wel kán natuurlijk. Maar via de Sessie is toch wel wat schoner/netter, imho.

[Verwijderd]

wolkje schreef op woensdag 27 februari 2008 @ 14:56:
[...]

Dat brengt allerlei interessante veiligheidsrisico's met zich mee, waar je wel goed over na moet denken. Want wát als ik de url even verander naar: "Edit.aspx?Id=345"?

Dat neemt niet weg dat het wel kán natuurlijk. Maar via de Sessie is toch wel wat schoner/netter, imho.

Via een Sessie schoner / Netter?

Je bent de eerste die ik zo iets hoor zeggen....

Een QueryString controleer je altijd op het juiste Type. Simpel.

Verder controleer je in je methode welke de gevens uit de db haalt ook op het juiste type.

[Cloud]

Verwijderd schreef op woensdag 27 februari 2008 @ 15:09:
Via een Sessie schoner / Netter?

Je bent de eerste die ik zo iets hoor zeggen....

Je moet het toch met me eens zijn dat een lege/geen querystring een stuk netter overkomt dan een querystring die niet eens meer in één adresbalk past.

Een QueryString controleer je altijd op het juiste Type. Simpel.

Verder controleer je in je methode welke de gevens uit de db haalt ook op het juiste type.

Ik heb het niet over het type, ik heb het over rechten. Het is simpel: je geeft je gebruikers de mogelijkheid zelf variabelen aan te passen, dus moet je meer controleren. Een probleem wat je bij sessievariabelen veel minder hebt, daar die niet aan te passen zijn door al je gebruikers.

Ook dit moet je met me eens zijn toch? Niets is onmogelijk en met querystring variabelen kun je ook prima werken, maar ik zou voor de meeste gevallen toch echt de sessie aanraden.

[Verwijderd]

wolkje schreef op woensdag 27 februari 2008 @ 15:15:
Je moet het toch met me eens zijn dat een lege/geen querystring een stuk netter overkomt dan een querystring die niet eens meer in één adresbalk past.

Je hebt een lijst daaruit klik je op edit. Wat maakt het uit wat er dan in de adresbalk past??
Verder gebruikt de topicstarter al een queryString.

Ik heb het niet over het type, ik heb het over rechten. Het is simpel: je geeft je gebruikers de mogelijkheid zelf variabelen aan te passen, dus moet je meer controleren. Een probleem wat je bij sessievariabelen veel minder hebt, daar die niet aan te passen zijn door al je gebruikers.

Dus om rechten te controleren zet je een Id van het te bewerken item in een Sessie?

Schiet mij maar lek.

ASP.Net heeft Membership en Role management gewoon aanboord.

En met deze methodiek scherm je je pagina's of mappen af.

code:

if(User.IsInRole("Admins"))
{
                
}

In de update methode geef je mee om welke user het gaat en in deze methode controleer je of de user iets mag aanpassen.

Ook dit moet je met me eens zijn toch? Niets is onmogelijk en met querystring variabelen kun je ook prima werken, maar ik zou voor de meeste gevallen toch echt de sessie aanraden.

Ik ben het absoluut met je oneens.

Een sessie is een geheugen-vreter, verloopt, is lastig bij multi server oplossingen enz.

[Cloud]

Verwijderd schreef op woensdag 27 februari 2008 @ 15:29:
Je hebt een lijst daaruit klik je op edit. Wat maakt het uit wat er dan in de adresbalk past??
Verder gebruikt de topicstarter al een queryString.

Het is netter, want je url is gewoon korter. Puur een esthetisch iets. Nu valt het bij één variabele nog wel mee, maar wat als je tien variabelen mee moet gaan geven?

Dus om rechten te controleren zet je een Id van het te bewerken item in een Sessie?

Schiet mij maar lek.

Volgens mij heb je echt geen idee waar ik het over heb inderdaad. Dat verhaal van de Membership- en Roleproviders is prachtig, maar heeft werkelijk niets te maken met wat ik je probeer duidelijk te maken.

Ik zeg alleen maar, dat als je al je variabelen via querystrings door gaat geven, je altijd moet controleren of de variabelen wel kloppen, d.w.z. niet door de gebruiker aangepast zijn in de querystring. En dat zul je moeten doen voor álle variabelen.

Stel je hebt een Delete.aspx die een row uit een database verwijderd. Als je de rowId doorgeeft via de querystring zul je dus op die Delete pagina moeten controleren of de variabele aangepast is of niet. Doe je dat via de Sessie, dan weet je zeker dat een gebruiker dat ID zelf niet aan heeft kunnen passen en dat scheelt je een check en je bent een veiligheidsrisico armer. Waarom moeilijk doen als het ook makkelijk kan?

En tuurlijk het kán allemaal via querystrings als je dat zo mooi vindt. Maar er is een goede reden dat je deze manier van variabelen doorgeven vrijwel nooit tegenkomt bij grote sites

Ik ben het absoluut met je oneens.

Een sessie is een geheugen-vreter, verloopt, is lastig bij multi server oplossingen enz.

Goh dan vraag ik me af waarom zoveel sites met sessies werken. De website waar jij nu op zit te surfen gebruikt ook sessies. En daarnaast, ik zie niet dat de TS bezig is met een multi-server oplossing (trouwens is dat makkelijk te overkomen, gewoon sessies via de database gaan opslaan en uitwisselen).

En het neemt inderdaad een beetje geheugen ja, maar waar denk je dat een ingelezen QueryString blijft? Een sessie verloopt inderdaad, maar dat doet jouw membershiplogin (die overigens met sessies werkt ) ook gewoon, dus dat argument gaat niet op.

edit:

Dit is overigens mijn laatste reactie hierover. Als je deze discussie voort wilt zetten moet dat in een ander topic Het is namelijk een tikkeltje offtopic.

[ Voor 3% gewijzigd door Cloud op 27-02-2008 16:09 ]

[farlane]

Volgens mij verandert je viewstate omdat je tussen je postback en de verwerking van je click functie de data in je grid zit te updaten waardoor er een ander record onder je rowindex komt.

Je tweede probleem kan alleen maar het gevolg zijn van ergens een Id oid hebben die application wide is.

[Hydra]

Verwijderd schreef op woensdag 27 februari 2008 @ 15:29:
Een sessie is een geheugen-vreter

Oh ja? Hoeveel overhead is er dan?

[Verwijderd]

wolkje schreef op woensdag 27 februari 2008 @ 15:48:
Ik zeg alleen maar, dat als je al je variabelen via querystrings door gaat geven, je altijd moet controleren of de variabelen wel kloppen, d.w.z. niet door de gebruiker aangepast zijn in de querystring. En dat zul je moeten doen voor álle variabelen.

Stel je hebt een Delete.aspx die een row uit een database verwijderd. Als je de rowId doorgeeft via de querystring zul je dus op die Delete pagina moeten controleren of de variabele aangepast is of niet. Doe je dat via de Sessie, dan weet je zeker dat een gebruiker dat ID zelf niet aan heeft kunnen passen en dat scheelt je een check en je bent een veiligheidsrisico armer. Waarom moeilijk doen als het ook makkelijk kan?

edit:

Dit is overigens mijn laatste reactie hierover. Als je deze discussie voort wilt zetten moet dat in een ander topic Het is namelijk een tikkeltje offtopic.

Het is inderdaad Offtopic...

Mijn laatste rectie...

Ik gebruik een Sessie als ik binnen de site de variabele op meerdere plaatsen nodig heb.(Bijvoorbeeld UserID)

Hoef ik het alleen door te geven aan de volgende pagina > QueryString

Ben je bang voor een cijfertje in de QueryString > Encryptie of gebruik een Guid

Bij een deltemethode zul je ALTIJD moeten controleren of de user dit wel mag of niet. Of je nu een Sessie gebruikt of een QueryString. Doe je dit niet, sorry maar dan ben je wat mij betreft echt fout bezig.

Verder zit het deleten niet in delete.aspx maar in de class van het object. Daar bouw je je controle mechanisme dus in. (bijkomend voordeeel, moet er ook een Winforms applicatie bij zorgt je class al voor de rechtencontrole)

Een querystring niet netjes? Kun je vinden, ik vind dat voor een edit pagina echt onzin. Net zoals Google daar bijvoorbeeld ook geen moeite mee heeft. Zoek maar eens wat in google en je zult je url zien veranderen..... met een QueryString :-)

Ieder zijn mening. No hard feelings.

[Hydra]

Verwijderd schreef op woensdag 27 februari 2008 @ 18:24:
Het is inderdaad Offtopic...

Mijn laatste rectie...

Ik zou graag hebben dat je uitlegt wat de overhead van sessies precies is. Ben enorm benieuwd nl.

[--MeAngry--]

Sorry voor de ietwat late reactie. Heb gisteren een dag vrij gehad en het bod wat we op een woning hebben gedaan is geaccepteerd, dus ineens is er veel voor de boeg.

Ondertussen heb ik wel de problemen opgelost en bleek ik weer veel te moeilijk te denken en op de verkeerde plaatsen te zoeken.
De problemen met het GridView op de current.aspx pagina heb ik opgelost door EnableViewState op true te zetten voor de GridView. Volgens MSDN is dit ook de manier om concurrent met dat component te werken.

quote: http://msdn2.microsoft.co...webcontrols.gridview.aspx

The GridView control is re-created on postback based on the information that is stored in ViewState. If the GridView control includes a TemplateField or a CommandField with the CausesValidation property set to true, then the EnableViewState property must also be set to true to ensure that concurrent data operations, such as updates and deletes, apply to the appropriate row.

Vervolgens de Edit.aspx pagina... Veel problemen bleken opgelost door EnableViewState aan te zetten. Echter wederom in het GridView met wat extra gegevens kwam het soms voor dat de verkeerde gegevens zichtbaar werden. (In de Edit.aspx pagina staat dus ook weer een GridView, maar dan met bepaalde gegevens van een persoon.)
Dit bleek dus te liggen aan de ObjectDataSource die ik daar gebruikte, deze was static, en de dataset die ik daaraan koppelde zette ik maar 1 keer vast, op het moment dat je de pagina voor het eerst binnenkomt.
Bij elke PostBack werd die ODS dus niet van de goede gegevens voorzien, maar worden de gegevens gebruikt die op dat moment in de ODS staan, en dat kunnen dus gegevens van een ander persoon zijn.

Ik voel me dom, just slap me around with a large trout.

Hydra schreef op donderdag 28 februari 2008 @ 00:24:
[...]


Ik zou graag hebben dat je uitlegt wat de overhead van sessies precies is. Ben enorm benieuwd nl.

Bij gebruik van een Sessie worden er gegevens op de server opgeslagen in plaats van dat je ze eenmaal met een QueryString meestuurt. Dat is dus de overhead.

[ Voor 24% gewijzigd door --MeAngry-- op 28-02-2008 14:03 ]