[ALG] forceren nieuwe sessie (cookie probleem)

[Cuball]

De gebruikte taal is wel in een Java Web omgeving, maar speelt niet echt zo'n rol. Het is eerder een methode die ik zoek.

kort een situatie schets: Ik heb een pagina waar een link staat met de verwijzing naar de webapplicatie. Deze opent in een nieuw scherm. Als de gebruiker de eerste keer klikt wordt een nieuw venster geopend en een nieuwe sessie geregistreerd, maar als er nog eens op die link geklikt wordt, dan wordt terug een nieuw venster geopend maar deze gebruikt dezelfde sessie (zelfde alsof je ctrl-n drukt in de browser, JSESSIONID blijft ongewijzigd).

Is er een mogelijkheid om een nieuwe sessie te "forceren" ? Voor session management wordt zoals vermeld gebruik gemaakt van cookies, url rewriting is niet echt een optie omdat de links leesbaar moeten blijven. En gebruik van hidden form fields heb ik geen ervaring mee. Maar ik denk dat deze methode teveel werk met zich zal meebrengen om de huidige applicatie ermee te doen werken.

Ik heb al eens geprobeerd om de link waar de gebruikers op klikken een jsp pagina, daar wat spelen met de cookies en deze redirecten naar een nieuwe pagina, maar dan loopt er van alles mis.

Verder dacht ik aan het gebruik van een filter maar ik zie geen manier om in men filter een onderscheid te maken tussen de 2 verschillende vensters en hier 2 verschillende sessies van te maken.

[Cuball]

het is ongeveer hetzelfde probleem als je CTRL-N drukt in InternetExplorer, dan werk je ook in het nieuwe scherm toch nog in de oude sessie. Maar hier klik je gewoon 2x op eenzelfde link

[ Voor 4% gewijzigd door Cuball op 27-10-2005 11:19 ]

[bigbeng]

Maakt de JSESSIONID misschien deel uit van de betreffende link? Dat wil nog wel eens voorkomen als url-rewriting (of zoiets) aanstaat.

[Cuball]

nee, ik maak geen gebruik van url-rewriting, niet echt een optie. Er wordt gebruik gemaakt van cookies, maar bij ctrl-n of door op die link te klikken wordt hetzelfe cookie dus terug gebruikt en dus krijg je dezelfde sessie

[djluc]

Je cookie op domein: d1.jedomein.com laten werken. Als je dan linkt naar: d2.jedomein.com zal je cookie niet meer geldig zijn en zal je een nieuwe sessie krijgen. Dat is eigenlijk de enige manier of je moet je bestaande sessie destroyen. Dat kan ook.

[Woy]

Wat is de reden dat je een nieuwe session wilt hebben? Mischien kan je het ook wel oplossen binnen dezelfde session

[Cuball]

ik heb nu iets als volgt gemaakt

redirectAndResetCookie.jsp

dit is een pagina die het kijkt of er een cookie bestaat en deze invalideerd, en daarna via een meta refresh doorstuurt naar de eigenlijke applicatie (die maakt dan een nieuwe sessie aan enzo)

als de gebruiker voor een 2de keer op deze link klikt dan wordt het bestaande cookie dus geinvalideerd en wordt de gebruiker terug naar de eigenlijke applicatie gestuurd.

Als ik nu in het eerste scherm van de applicatie uitschrijf wat in de sessie zit dan zie ik dat beide windows een verschillend session object hebben.

Maar van zodra ik navigeer op men applicatie dan wordt ook in het eerste window gebruikt gemaakt van het 2de session object wat natuurlijk niet zou mogen en voor veel fouten kan zorgen, dit waarschijnlijk doordat hij het cookie inleest van het andere scherm (en dit bevat dan het sessionid van het andere scherm)

ik vraag me af wat het verschil dan juist is tussen het 2x openen van internet explorer?

ik weet echt niet meer hoe ik hier verder kan

[ Voor 12% gewijzigd door Cuball op 27-10-2005 14:51 ]

[Woy]

rwb schreef op donderdag 27 oktober 2005 @ 12:06:
Wat is de reden dat je een nieuwe session wilt hebben? Mischien kan je het ook wel oplossen binnen dezelfde session

??

[djluc]

Wat je wil kan niet als je niet op aparte domeinen --en dus met aparte cookies-- werkt. Je moet dus niet zomaar je cookies gaan deleten want je browser krijgt dan gewoon je andere cookie zoals je gemerkt hebt.

Je opties zijn dus:
-Subdomein gebruiken
-Dezelfde cookie in de applicatie gebruiken
-De user een nieuwe instantie van de browser laten openen, dus in plaats van een nieuwe venster opnieuw op de snelkoppeling klikken om een instantie van IE of FF te laten starten.

[Cuball]

ja maar hoe forceer je de gebruikers dit te doen ? Nu staat een link op het intranet naar deze applicatie en de gebruikers klikken gewoon op die link om het programma te openen, met alle gevolgen vandien

[Cuball]

djluc schreef op donderdag 27 oktober 2005 @ 14:49:
-De user een nieuwe instantie van de browser laten openen, dus in plaats van een nieuwe venster opnieuw op de snelkoppeling klikken om een instantie van IE of FF te laten starten.

ja maar hoe forceer je de gebruikers dit te doen ? Nu staat een link op het intranet naar deze applicatie en de gebruikers klikken gewoon op die link om het programma te openen, met alle gevolgen vandien

[Cuball]

rwb schreef op donderdag 27 oktober 2005 @ 14:48:
[...]

??

de applicatie wordt geopend via een link op een intranet applicatie,het is een soort ticket systeem met taken en dergelijke en gebruikers hebben graag enkel schermen openstaan met de verschillende taken waar ze mee aan het werken zijn.

[djluc]

Cuball schreef op donderdag 27 oktober 2005 @ 14:52:
[...]
ja maar hoe forceer je de gebruikers dit te doen ? Nu staat een link op het intranet naar deze applicatie en de gebruikers klikken gewoon op die link om het programma te openen, met alle gevolgen vandien

Dat kan je doen door uitleg te geven: Klik op start->programma's->blabla of je maakt bijvoorbeeld een bat bestandje wat je uitvoert. Hiervoor moet je wel de security even laag zetten maar dat maakt opzich niet uit in een beschermde omgeving.

Batchfile:

# syntax moet je even checken/testen want die klopt niet precies denk ik
"c:\program files\internet explorer\explorer.exe http://jeserver/hoi.jsp"

[ Voor 15% gewijzigd door djluc op 27-10-2005 15:10 ]

[Hydra]

Waarom maak je niet voor gebruikers een soort 'task' ID aan, zodat ze gewoon met meerdere schermen open kunnen zitten? Kennelijk is daar een behoefte aan. SessionID + TaskID = Uniek. Die Task ID kun je dan via de URL naar opvolgende pagina's doorgeven. Heb je geen Task ID, dan maak je een nieuwe aan (gebaseerd op de huidige tijd bijvoorbeeld).

[Woy]

Cuball schreef op donderdag 27 oktober 2005 @ 14:53:
[...]


de applicatie wordt geopend via een link op een intranet applicatie,het is een soort ticket systeem met taken en dergelijke en gebruikers hebben graag enkel schermen openstaan met de verschillende taken waar ze mee aan het werken zijn.

Hoezo zou je dit niet binnen een enkele Sessie kunnen doen? Je moet er inderdaad voor zorgen dat je per Pagina gewoon een TaskID bijhoud zoals Hydra al zegt. Als je toch nog gegevens per Task in je Session nodig hebt kun je die idd gewoon in je session stoppen aan de hand van een TaskID.

[Cuball]

ja een TaskId is inderdaad wel een mogelijkheid, maar het betreft een bestaande applicatie en de tijd die we krijgen om het probleem op te lossen is beperkt. Op het eerst zicht lijkt het misschien niet zo veel werk om te dit te implementeren maar het is nogal een drastische wijziging volgens mij en zal (te) veel tijd in beslag nemen om terug volledig grondig testen.

Wel klein vraagje, we werken met struts, dus per taskId zou je dan een nieuwe formbean aanmaken (hiervoor moet dan een uitbreiding op struts geschreven worden)? Of zou je eerder opteren om in de formbean een soort map van tussen (form)objecten bij te houden en die dan via een TaskId key opgehaald kunnen worden uit de map? Maar hoe dan verder?wat doe je bij een submit? Volgens mij lijkt dit toch wel veel werk.

[Hydra]

Cuball schreef op vrijdag 28 oktober 2005 @ 08:36:
ja een TaskId is inderdaad wel een mogelijkheid, maar het betreft een bestaande applicatie en de tijd die we krijgen om het probleem op te lossen is beperkt. Op het eerst zicht lijkt het misschien niet zo veel werk om te dit te implementeren maar het is nogal een drastische wijziging volgens mij en zal (te) veel tijd in beslag nemen om terug volledig grondig testen.

Dat kun je alleen zelf bepalen. Ik weet niet hoeveel data er bijgehouden wordt, maar mij lijkt het niet erg moeilijk een sessie een task collection (hashtable) te geven, waar je dan die tasks in stopt. Neem aan dat je die data in een class hebt zitten.

Het is jouw applicatie. Als je een smerige oplossing wil kan ik je wel 't nummer van een ex-collega geven

Wel klein vraagje, we werken met struts, dus per taskId zou je dan een nieuwe formbean aanmaken (hiervoor moet dan een uitbreiding op struts geschreven worden)? Of zou je eerder opteren om in de formbean een soort map van tussen (form)objecten bij te houden en die dan via een TaskId key opgehaald kunnen worden uit de map? Maar hoe dan verder?wat doe je bij een submit? Volgens mij lijkt dit toch wel veel werk.

Ik zou ten eerste niet zo snel in paniek raken. Ik ken struts niet, maar een pagina/task heeft data. Het enige wat je hoeft te doen is die data/page staat in een object te stoppen, en die in een task-collection op te slaan. Als je een pagina opent, en er is een task-id meegegeven, haal je simpelweg de bijbehorende state op.

[Gwaihir]

Hydra schreef op donderdag 27 oktober 2005 @ 18:20:
Waarom maak je niet voor gebruikers een soort 'task' ID aan, zodat ze gewoon met meerdere schermen open kunnen zitten? Kennelijk is daar een behoefte aan. SessionID + TaskID = Uniek. Die Task ID kun je dan via de URL naar opvolgende pagina's doorgeven. Heb je geen Task ID, dan maak je een nieuwe aan (gebaseerd op de huidige tijd bijvoorbeeld).

Dat helpt helaas niet wanneer een gebruiker een nieuw venster erbij opent. Dat neemt het TaskID gewoon van het oude over (bij IE 6.0 althans).

Ik worstel met hetzelfde probleem (in een PHP webapplicatie). Ik heb er uiteindelijk voor gekozen alle voor de taak relevante statusinfo in een verborgen veld mee naar de browser te sturen en zo van de client terug te ontvangen bij het volgende verzoek. Daar het een intranet-applicatie is, geeft dat qua dataverkeer geen problemen.

Hmm.. een TaskID zou wel moeten werken als je het per taak wijzigt:
-> ik open een extra venster -> heb er twee met hetzelfde TaskID
-> ik ga iets anders doen in dat extra venster (doe tenslotte niet 2x hetzelfde) -> ik krijg daar een nieuw TaskID
Moet je wel verdomd goed opletten wat wel en niet een nieuwe taak is en / of hoe je eventueel na afronding van een nieuwe sub-taak weer met een oude taak verder gaat.

[Cuball]

Ik wou nog eventjes terugkomen op het originele probleem. Blijbkaar doet dit zich ook voor als de gebruiker op een link klikt in outlook. Op elke link die geklikt wordt en naar dezelfde applicatie linkt krijgt dezelfde sessionId, met alle gevolgen vandien... (ik wijzig iets in het ene venster bewaar en den wijzig ik iets in het andere venster (zelfde session) en bewaar terug, gegevens uit het ene scherm worden dan overschreven zonder foutboodschap of dergelijke)

wat ik me afvroeg of er iemand al een oplossing gevonden heeft om bv gewoon het scherm af te sluiten als er een 2de venster geopend wordt met dezelfde session. Ik heb al wat zitten proberen in een filter en random iets bijhouden in een hashmap, maar ik geraak er niet echt uit

[Janoz]

Het probleem is dat hetgeen jij wilt compleet onmogelijk is met enkel sessies. Een browser weet niet dat 1 specifiek scherm bij 1 cookie hoort en dus bij 1 sessie hoort. Zodra een cookie geset wordt geldt dat voor die computer.

Ik vermoed dat je een bepaalde wizzard start oid waarin je meerdere schermen moet doorlopen om iets in te vullen. Je kunt dan beter naast de sessie ook een soort 'wizzard token' meenemen. De resultaten van een wizzard zet je in een object. Dit object zet je niet in de session, maar zet je in een hashmap met dat 'wizzard token' als key. Op die manier kun je de verschillende wizzards uit elkaar halen.

[Cuball]

Het is geen wizard, maar dat speelt niet zo'n rol.

Maar ik kan met niet voorstellen dat niemand anders dergelijk probleem heeft voorgehad? Wij zitten nu in ons programma met 100endubbele records doordat gebruikers 2x hetzelfde scherm open staan hebben met zelfde sessionId en dan bij het bewaren van 1 van de schermen gegevens uit het andere overschreven worden.

Ik zou nu een soort filter willen schrijven oid dat kijkt of er al een session aanwezig en deze registreert, hierin dan een controle of er ook een token aanwezig is, indien dit zo is, dan is het OK. Als er geen token aanwezig is en deze sessie staal al geregistreerd dan is het omdat de gebruiker een nieuw venster van de browser heeft geopend ipv een nieuwe instantie, dit moet dus de actie blokeren.

[Janoz]

Dat je nu onbedoelde dubbele records hebt geeft mij het idee dat er iets grondig mis is in de architectuur van die applicatie. Daarnaast krijg ik ook niet echt het idee dat het concept van sessies en cookies om in het stateless http protocol toch nog enige vorm van state informatie te krijgen bij jouw helemaal duidelijk is.

Een gebruiker heeft op een computer ALTIJD dezelfde sessie id. Een gebruiker kan immers maar 1 cookie met de naam JSESSIONID hebben. Hoe moet een scherm nu weten of hij het bestaande koekje of een nieuwe moet gebruiken?

[Cuball]

Janoz schreef op dinsdag 09 mei 2006 @ 13:26:
Daarnaast krijg ik ook niet echt het idee dat het concept van sessies en cookies om in het stateless http protocol toch nog enige vorm van state informatie te krijgen bij jouw helemaal duidelijk is.

Ik vind het nogal zwak om zo'n uitspraken te doen, ik heb toch niet gevraagd wat jij denkt over mijn kennis? Ik zou het bij het topic houden ipv anderen af te breken.

Een gebruiker heeft op een computer ALTIJD dezelfde sessie id. Een gebruiker kan immers maar 1 cookie met de naam JSESSIONID hebben. Hoe moet een scherm nu weten of hij het bestaande koekje of een nieuwe moet gebruiken?

En misschien moet je zelf terug wat kennis opdoen, het is zo dat een cookie gedeeld wordt door 1 instantie van een browser (IE toch zeker) dus als je in een nieuw scherm opent binnen deze instantie (ctrl-n bv) dan krijg je uiteraard voor elk scherm het zelfde cookie. Als je met verschillende instaties werkt van internet explorer heb je een ander cookie met daarin dus een andere waarde voor de JSESSIONID (het cookje heet trouwens niet JSESSIONID, maar de key van key/value pair heet sessionID)

en hoe kan je me nu gaan afbreken op de architectuur ? Er staat niets in mijn post vermeld over hoe de toepassing is opgebouwd. Maar er wordt wel degelijk gebruikt gemaakt van concurrency control (via optimistic locking in hibernate).

Het probleem doet hem voor opdat 2 schermen van eenzelfde browser dezelfde datadelen, dus om een kort voorbeeldje te geven waar het verkeerd gaat:

ik heb een object A met een versionID = 1. Ik bewaar dit object in het scherm1 dat open staat, de update wordt uitgevoerd en het versionID wordt verhoogd. Nu bewaar ik het scherm2 (die dezelfde sessie deelt) deze kijkt naar de versionID en deze is 2 (omdat we in scherm1 bewaard hebben en objectA dat gelinkt is aan de sessie geupdated hebben en dus is de versionID verhoogd). Maw het objectA wordt terug bewaard zonder ook maar 1 fout te geven op een concurrency fout.

[Creepy]

Cuball schreef op dinsdag 09 mei 2006 @ 14:28:
[...]


En misschien moet je zelf terug wat kennis opdoen, het is zo dat een cookie gedeeld wordt door 1 instantie van een browser (IE toch zeker) dus als je in een nieuw scherm opent binnen deze instantie (ctrl-n bv) dan krijg je uiteraard voor elk scherm het zelfde cookie. Als je met verschillende instaties werkt van internet explorer heb je een ander cookie met daarin dus een andere waarde voor de JSESSIONID (het cookje heet trouwens niet JSESSIONID, maar de key van key/value pair heet sessionID)

Eeeh.. een cookie wordt op je PC opgeslagen op 1 plek. Het maakt dus niet uit hoeveel verschillende windows e.d. je open hebt staan, er blijft maar 1 cookie beschikbaar en niet meerdere cookies per scherm/sessie in IE.
Dat er een andere sessie (op de server ) wordt gestart en hierdoor je cookie een andere naam krijgt indien er een nieuwe sessie van IE wordt gestart is iets heel anders en ligt waarschijnlijk aan de gebruikte architectuur. Hier wordt feiloos dezelfde sessie opgepikt (want hetzelfde IP en hetzelfde cookie worden gebruikt) in zowel Java en PHP..

Op het moment dat een gebruiker meerdere "dezelfde" schermen open kan hebben staan dan is de sessie voor het opslaan van gegevens van dit scherm niet bruikaar. Je zult het dus echt op een andere manier moeten oplossen. Dit kan o.a. met het gebruik van hidden form fields zoals je zelf ook al aangaf.

[ Voor 13% gewijzigd door Creepy op 09-05-2006 14:38 ]

[Cuball]

Dat er een andere sessie (op de server ) wordt gestart en hierdoor je cookie een andere naam krijgt indien er een nieuwe sessie van IE wordt gestart is iets heel anders en ligt waarschijnlijk aan de gebruikte architectuur. Hier wordt feiloos dezelfde sessie opgepikt (want hetzelfde IP en hetzelfde cookie worden gebruikt) in zowel Java en PHP..

Ik heb het eens in firefox geprobeerd en daar krijg ik inderdaad dezelfde sessie terug als ik een nieuwe instantie opstart, maar we gebruiken enkel internet explorer en bij deze krijg je effectief 2 verschillende sessies op de server en ook in de browser zelf wordt er nog een onderscheid gehouden, hoe kan dit dan als er maar 1 cookie gebruikt wordt ?

Op het moment dat een gebruiker meerdere "dezelfde" schermen open kan hebben staan dan is de sessie voor het opslaan van gegevens van dit scherm niet bruikaar. Je zult het dus echt op een andere manier moeten oplossen. Dit kan o.a. met het gebruik van hidden form fields zoals je zelf ook al aangaf.

klopt inderdaad, en die detectie (ofdat 2 schermen openstaan) wil ik nu implementeren, zonder het gebruik van cookies ongedaan te maken (het moet er naast kunnen werken). (Hidden form field heb ik geen ervaring mee en de applicatie bestaat uit heel wat forms, het zou te omslachtig zijn om hier overal hidden fields aan toe te voegen)

[Janoz]

Ik heb hier IE. Dagelijks druk ik meerdere keren op ctrl-n, en ik ben nog steeds ingelogd bij tweakers. Ook mijn eigen applicaties (j2ee applicaties) houden gewoon dezelfde sessie id. Ook als ik op ctrl-n druk. Dat alles is onderdeel van de te verwachten werking. Een cookie werkt neit per scherm. Een cookie werkt per gebruiker en computer. Je kunt wel zeggen dat het niet zo is, maar je applicatie werkt ook niet.

De ENIGE manier om dit op te lossen is om in je window zelf bij te houden om welke instantie het gaat. Echter, zolang je niks wilt aanpassen aan de bestaande formulieren zul je het probleem niet op kunnen lossen.

De reden dat ik twijfel aan de architectuur is omdat er dubbele records in de database staan en omdat de goede werking afhankelijk is van een statefull client die helemaal niet statefull is. Ik zeg verder niks over de achterkant aangezien ik daarvan inderdaad nog niks heb kunnen zien. Echter bied de voorkant de mogelijkheid om transacties volledig te omzeilen. Daaruit trek ik de conclusie dat er (mbt de voorkant) iets niet klopt aan de architectuur.

[Janoz]

Aangezien je het van mij niet aanneemt heb ik het even opgezocht:

RFC 2109:

4.3.3 Cookie Management

If a user agent receives a Set-Cookie response header whose NAME is
the same as a pre-existing cookie, and whose Domain and Path
attribute values exactly (string) match those of a pre-existing
cookie, the new cookie supersedes the old. However, if the Set-
Cookie has a value for Max-Age of zero, the (old and new) cookie is
discarded. Otherwise cookies accumulate until they expire (resources
permitting), at which time they are discarded.

RFC 2965

3.3.3 Cookie Management If a user agent receives a Set-Cookie2
response header whose NAME is the same as that of a cookie it has
previously stored, the new cookie supersedes the old when: the old
and new Domain attribute values compare equal, using a case-
insensitive string-compare; and, the old and new Path attribute
values string-compare equal (case-sensitive). However, if the Set-
Cookie2 has a value for Max-Age of zero, the (old and new) cookie is
discarded. Otherwise a cookie persists (resources permitting) until
whichever happens first, then gets discarded: its Max-Age lifetime is
exceeded; or, if the Discard attribute is set, the user agent
terminates the session.

Zoals je kunt lezen zal, wanneer er een tweede cookie gestuurd wordt, deze de vorige overschrijven. En dat is exact het gedrag dat je hier ( [rml]Cuball in "[ ALG] forceren nieuwe sessie (cookie pro..."[/rml] ) ook beschrijft.

[Cuball]

dit is inderdaad wat ik krijg,

maar het verklaart wel niet de resultaten die ik heb in IE wanneer ik 2 instaties open dat deze 2 verschillende SESSIONID's krijgen. Wat wel vreemd is dat ik geen cookies te zien krijg in de temp folder van IE die bij men toepassing zouten moeten horen.... Misschien iets verkeerd met websphere, maar daar heb ik nogtans aangegeven dat session management via cookies moet werken...

bizar

[Janoz]

Websphere heeft er niets mee te maken. Het is puur een client aangelegenheid. Het zou best kunnen dat een cookie die niet op de schijf wordt opgeslagen (een zogenaamde session cookie, niet te verwarren met een serverside session. Zo'n session cookie bestaat alleen in het geheugen en wordt verwijderd zodra de browser gesloten wordt) niet wordt meegenomen wanneer je een tweede instantie van IE opstart. Dan zou het misschien kunnen zijn dat je twee losse instanties van IE hebt lopen die elk hun eigen geheugen gebruiken waarin in elk een eigen cookie zit. Dit zal je echter nooit kunnen uitbuiten omdat het vanaf een weblinkje niet mogelijk is om deze te openen in een compleet nieuwe instantie van IE (dus NIET enkel een nieuw window).

[Cuball]

dat zal het inderdaad kunnen zijn, IE houdt dat ding in z'n geheugen bij... ik vraag me dan wel af waarom dit niet weggeschreven wordt?!

[ Voor 7% gewijzigd door Cuball op 10-05-2006 08:18 ]

[Verwijderd]

Enkel als je een langere lifetime zet...

[matthijsln]

Cuball schreef op dinsdag 09 mei 2006 @ 14:28:
[...]
en hoe kan je me nu gaan afbreken op de architectuur ? Er staat niets in mijn post vermeld over hoe de toepassing is opgebouwd. Maar er wordt wel degelijk gebruikt gemaakt van concurrency control (via optimistic locking in hibernate).

Het probleem doet hem voor opdat 2 schermen van eenzelfde browser dezelfde datadelen, dus om een kort voorbeeldje te geven waar het verkeerd gaat:

ik heb een object A met een versionID = 1. Ik bewaar dit object in het scherm1 dat open staat, de update wordt uitgevoerd en het versionID wordt verhoogd. Nu bewaar ik het scherm2 (die dezelfde sessie deelt) deze kijkt naar de versionID en deze is 2 (omdat we in scherm1 bewaard hebben en objectA dat gelinkt is aan de sessie geupdated hebben en dus is de versionID verhoogd). Maw het objectA wordt terug bewaard zonder ook maar 1 fout te geven op een concurrency fout.

Dit lijkt meer op het verkeerd gebruiken van Hibernate Sessions, want als je zomaar een Session in je HttpSession stopt krijg je problemen (tenzij je bewust het "session-per-conversation" pattern gebruikt, zie http://www.hibernate.org/42.html).

Daarnaast zou ik zowiezo zorgen voor primary keys en evt andere constraints in je database om dubbele records te voorkomen.

[Cuball]

Ik gebruik session-per-request strategy, men sessie wordt dus gebonden aan een threadlocal variabele en deze wordt afgesloten als men view volledig af is (OpenSessinInViewFilter van spring gebruik ik hiervoer)

maar misschien is er inderdaad iets wat ik verkeerd doe, nu gaat het als volgt:

ik haal een entity op via hibernate: bv Persoon deze plaatst ik op een ActionForm (struts) en laat ik wijzigen door de gebruiker. De gebruiker kan deze bewaren (transactie met isolatie level reapeatable read + een version property in hibernate). Maar als de gebruiker nu een nieuw scherm opent adhv ctrl-n wanneer deze een persoon aan het wijzigen is, dan delen deze beide schermen hetzelfde persoon object dat in de ActionForm zit (deze form heeft session scope). Dus als de gebruiker een wijziging maakt in het ene scherm en dan de persoon bewaart en dan een wijziging in het 2de scherm (dat nog open staat) en ook bewaart lukt dit probleemloos zonder fouten en zijn de gegevens die gemaakt zijn in het eerste scherm verloren.

ik heb net eventjes getest hier op tweakers, als ik een post edit, dan ctrl-n doe, in het ene venster iets bewaar en dan in het andere ook bewaard, dan zijn de wijzigingen in het eerste venster verloren gegaan.... is dit normaal gedrag ?

Ik heb geen dubbele records in men tabel zitten, soms worden gegevens van het ene object weggeschreven bij het andere object en vica versa (bv items van een collectie), dit omdat gebruikers verschillende vensters open hebben staan met andere gegevens in dezelfde sessie.

nog een voorbeeld om het laatste de verduidelijken,
scherm1 : Ik open PersoonA, druk op control-n
scherm2: Ik open PersoonB

in feite kan er nu maar 1 Persoon object zijn, want het Persoon object bevindt zich op de form en deze heeft een sessionscope, en aangezien de 2 schermen dezelfde sessie hebben zou dit hetzelfde object moeten zijn.

nu bewaar ik PersoonA in scherm1 en hier loopt het dan soms fout, bv een property van PersoonB wordt nu geupdated in het record van PersoonA en omgekeerd...

maak ik een redeneringsfout of wat loopt er verkeerd ?

[matthijsln]

En als je de scope van je form op "request" zet ipv "session"?

Eventueel kan je ook met een Struts tokens werken (isTokenValid() en saveToken()).

[Cuball]

matthijsln schreef op woensdag 10 mei 2006 @ 10:48:
En als je de scope van je form op "request" zet ipv "session"?

dit is niet zomaar te doen, we hebben redelijk wat gegevens op de forms die moeten kunnen gebruikt worden tussen de verschillende schermen.

Eventueel kan je ook met een Struts tokens werken (isTokenValid() en saveToken()).

Ik heb het zonet bekeken, en dat lijkt wel te werken.

Maar we hebben nog een ander probleem in onze applicatie die nog niet opgelost is, omdat de form enctype="multipart/form-data" ingesteld staat verliest struts op een of andere manier onze request parameters (dus ook het hidden form field die saveTaken aanmaakt).