JaarMedlem sedan juli 2001434 inlägg Jag har skapat mig själv ett problem.
Först tar jag miljön, och problemet som är där.
Jag har en connectionpool som verkar ta slut, eller kopplas ned. För den är helt enkelt passiv när det inte varit besökare på ett tag och första uppkopplingen mot dataasen tar ett tag. Lika så jsp sidorna/javamotorn verkar ha varvat ned så sidan tar ett tag att ladda.
Jag har en sida på en annan webbserver där man kan fylla i ett formulär. Detta postas till en jsp-sida som kollar så att uppgifterna inte är sparade sedan tidigare, och sedan gör en insert.
Problemet är att när användaren trycker på skicka in, så ser det inte ut som det händer något iom att jsp+connection är i dvala. Vad denne gör då är att trycka några gånger till.
Detta gör att det kommer 4-5 anrop till jsp sidan och alla processas. Tiden mellan det att selecten för att kolla dublett och insert körs gör att det kommer 2-3 dubletter innan den första selecten "slår ifrån".
Jag antar att detta har med "segheten" att göra, eller alternativt att selecten är cachad (prepared statement)?
Hur löser jag detta? Jag skulle vilja låsa tabellen för de andra sidorna tills inserten är klar.
erkaMedlem sedan dec. 19996 522 inlägg Vilket DBMS kör du med, stored procedure?
JaarMedlem sedan juli 2001434 inlägg Jag har en oracle databas som står på en egen maskin (innanför brandväggen)
Idag finns det ingen storeprocedure utan det körs som två separata statement anrop i koden.
@ndersMedlem sedan juni 200032 969 inlägg En lösning skulle ju kunna vara att du disablear "skicka"-knappen när användaren klickar på den, och ser till att användaren förstår att servern arbetar.
Mvh
spangoMedlem sedan juni 20008 205 inlägg Stoppa in ett "unikt" värde (typ en timestamp) i ett dolt formulärfält på sidan som skickar. När du tar emot ett anrop, stoppa in det värdet i användarens session. Finns det redan där, låt bli att stoppa in nåt i databasen. På det sättet kan bara ett formulär bara skickas in en gång. Komplettera sedan med @nders variant.
erkaMedlem sedan dec. 19996 522 inlägg @nders förslag fungerar, är det för en publik site kan du ju generera en engångskod på sidan som användaren får skriva in, om koden stämmer och inte finns i databasen sätt in den, på det viset slipper du missbruk via spam agents etcetera på köpet. Vill du låsa dina tabeller kan du göra det men ser inte att det skulle få bort ditt problem
JaarMedlem sedan juli 2001434 inlägg
spango skrev:
Stoppa in ett "unikt" värde (typ en timestamp) i ett dolt formulärfält på sidan som skickar. När du tar emot ett anrop, stoppa in det värdet i användarens session. Finns det redan där, låt bli att stoppa in nåt i databasen. På det sättet kan bara ett formulär bara skickas in en gång. Komplettera sedan med @nders variant.
@nders förslag är ju ganska klassiskt (men löser bara på klientsidan och känns lite som ett dirtywork)
Problemet med ditt sätt är att efter det att användaren postat in formuläret kommer denne att få ett meddelande med lämplig text eller en redirect.
Om jag kollar parameter kommer jag inte veta id på den posten som skapades, och det har ju ännu inte hunnit skapats upp i databasen (inte garanterat iaf).
Det man skulle kunna göra är att spara det värdet inne i databasen också och göra en select efter det värdet i efterhand.
Är det någon som vet hur man förhindrar att tomcat "varvar ned"?
Det är som att den kompilerar om hela lösningen om det inte varit aktivitet på länge. Ett anrop kan då ta över 5 sek innan den börjar processa vilket inte känns så bra. Det är inget annat som körs på maskinen så jag vill ju hålla igång den hela tiden, även utan besökare.
Tack för er hjälp
spangoMedlem sedan juni 20008 205 inlägg
Jaar skrev:
Problemet med ditt sätt är att efter det att användaren postat in formuläret kommer denne att få ett meddelande med lämplig text eller en redirect.
Om jag kollar parameter kommer jag inte veta id på den posten som skapades, och det har ju ännu inte hunnit skapats upp i databasen (inte garanterat iaf).
Mitt sätt är mer ett komplement till @nders, vars enda avsikt är att förhindra att samma formulär postas två gånger, så att det inte blir två likadana poster i databasen. Klickar användarna på submit två gånger får de liksom skylla sig själv när det står "du har redan postat det här, pucko" på sidan de skickar till ;)
Ditt verkliga problem är ju egentligen ett synkroniseringsproblem...
intesaMedlem sedan apr. 2006190 inlägg En elegantare lösning kanske skulle vara att använda sig av EJBs med transactions som sköter det där? Men det kanske är overkill för din applikation?
Kan det vara så att du har aningens för lite RAM i burken så att web containern kastar ut alla instanser från minnet vid inaktivitet, så den måste skapa nya när en klass anropas?
