Hallo

>Du kannst auch eine "Neuen Warenkorb starten"-Funktion anbieten, ggf.
>Sogar mit Speicherung mehrerer Warenk�rbe...
>Und letztendlich kannst Du auch automatisch beim neuen einloggen den
>Warenkorb l�schen, wenn der letzte Login mehr als x Stunden(x=24?) her
>ist.
>Dadurch l�st Du das Problem mit dem verlorenen WK, aber handelst Dir
>keine neuen ein.

Ich werde einen machen. Das andere k�nnte nur wieder einige Leute verwirren.

> > Aber wie  finde ich heraus, dass die Session abgelaufen ist
> > und er nicht
> > einfach komplett neu
> > in den Shop gekommen ist?
>
>Das kannst Du nicht, aber wof�r soll das wichtig sein? Das konntest Du
>doch vorher auch nicht...
>Und wenn er einen zweiten Browser aufmacht, kann er sich mit neuer
>Session einloggen...
>Da der WK nun aber nicht mehr Session-Abh�ngig ist, sondern von der
>User-ID, hat er in beiden Sessions den gleiche Warenkorb... Noch ein
>Problem gel�st!

Jep, werd ich gleich so �ndern.

>3. In der DB speichert man dann mit der entsprechenden SessionID
>dazugeh�rige Daten, z.B. userID etc.

Also doch wieder mit Sessions arbeiten?

>4. Diese Sessions k�nnen auch einen Timeout haben, aber der kann h�her
>angesetzt werden, weil die Session nicht im Speicher gehalten wird,
>sondern in einer DB.

Ah, keine Session("ID")=..... sondern nur die SessionID auslesen?

>7. Um Performance zu steigern, kann man das System so bauen, dass
>Session-Daten f�r eine bestimmte Zeit(z.B. 10min oder 20min) innerhalb
>des Applikation-Objects gecacht werden und danach gel�scht werden...

Das Applikations-Objekt ist doch f�r alle User g�ltig, oder?Gibt es eine 
M�glichkeit,
das zu starten, ohne den Server neu zu starten?

>Dadurch hat man den Vorteil von IIS-Sessions(schnell, weil im Speicher)
>und DB-Session(lange Timeouts, weil in der DB).
>Wenn dann einer aktiv surft, hat er gute Performance, weil seine
>Session-Daten im Appliaktion-Object gecacht werden... Geht er
>zwischendurch f�r eine halbe Stunde zum Telefon, wird einfach beim
>ersten Aufruf wieder das Zeug aus der DB geholt und weitere Anfragen
>kommen wieder aus dem Cache...

Hmm, das mit diesem Applikation-Cache hab ich noch ned so verstanden.
Muss mich mal informieren.

>Solch ein System w�re am performantesten als COM-Object implementiert,
>aber auch als Skript kann das schnell genug sein...
>Ich habe so ein �hnliches System schon mal implementiert...
>Querystring-Sessions; als Speicherplatz freethreaded XMLDom in
>Application-Variable; keine DB-Persistenz. Beliebiebige Typen(String,
>Int, Date, beliebig tief geschachtelte Arrays etc.) werden ins XMLDom
>persistiert.

Puh, das ist etwas hoch f�r mich.
Danke trotzdem. Werde mich �ber die div. Vorschl�ge, welche ich noch nicht 
zu 100% begriffen habe, genauer informieren.
Wieviel Speicher braucht denn eine Session??
In der aktuellen Version arbeite ich sehr viel mit Session. Sprich, 
speichere viel in den div. Sessions ab.

Gruss Christoph



| [aspdecoffeehouse] als [email protected] subscribed
| http://www.aspgerman.com/archiv/aspdecoffeehouse/ = Listenarchiv
| Sie k�nnen sich unter folgender URL an- und abmelden:
| http://www.aspgerman.com/aspgerman/listen/anmelden/aspdecoffeehouse.asp

Antwort per Email an