samtigdighed

Ja.

Hvis en request laver SELECT og en anden request laver UPDATE kan du godt
få problemer med 2 samtidige brugere.

Det kan deles op i 2 punkter...

1 : Indsætning af poster - Dette kan jeg ikke se vil give problemer...

2 : Opdatering af poster - Denne er mere usikkert... Du skal sørge for at "bruger 2" ikke kan komme til at opdatere en post hvis "bruger 1" allerede er igang... Dette kan evt gøre ved at lave et felt i databsen der hedder fx "opdateres" .... det så så sættes = "bruger 1" hvis det er den bruger der opdatere feltet... Når det så er sket skal det nulstilles, og "bruger 2" kan nu komme til at opdatere...

Det er hva jeg har benyttet mig af tidligere.. Godt nok ikk i JAVA, men i ASP...

scenario:
bruger 1 henter record X
bruger 2 henter record X
bruger 1 opdatere record X
bruger 2 opdatere record X

så kan bruger 1's rettelse rblive overskrevet.

Der er flere mulige løsninger:

1)  Du bruger versions nummer på data.

2)  Din web app låser recorden via database specifikke kald
    (kræver at connection gemmes i session) f.eks. SELECT FOR UPDATE.

3)  Din web app holder selv styr på hvad der er hentet uden at være
    blevet opdateret (i single server env kan det gøres med en singleton).

4)  Du laver et felt til at markere "i brug"

Jeg vil helt klart anbefale #1.

jeg kalder en metode i java der står for at udføre alt det der skal udføres inden der skal gemmes. Spørgsmålet er nærmere om de data der ligger i modellaget bliver ændret. Hvis der er to der kalder den samme metode i jsp, der så kalder den samme metode i java. Hvad sker der så, kommer de automatisk i kø, eller hvordan gøres dette. Jeg overvejer bare at lave synchronize ved de metode der startes med at blive kaldt. Det er jo begrænset hvor meget ventetid der vil være.!

"Version Number Pattern" er standard i EJB verdenen.

Og i de fleste EJB bøger.

For en online ressource læs:
http://www.josseybass.com/cda/cover/0,,0471208310%7Cexcerpt,00.pdf

[selvom du ikke bruger EJB kan du godt lave noget tilsvarende]

Hvis det er en ren opdatering d.v.s. ar der ikke er en hent inden
opdater, så er situationen meget simplere.

Database adgang bør slet ikke være et problem. Stansdard database
transactions sørger for at det virker.

Hvis der opdateres "in memory" data-strukturer skal der muligvis
synkroniseres på disse.

Formentlig vil det være bedst at synkronisere på selve objekterne
i.s.f. at lave synchronized metoder.

Men det er svært at sige uden at kende detaljer.

jeg har hent metoder i mine databasemetoder, derfor skal jeg nok lave synkronizeringen højere oppe. Men tjekker lige linket...

Det store spørgsmål er om brugeren henter en JSP side med de data,
retter i dem og submitter til en JSP side der opdaterer i databasen.
Eller det hele sker i en enkelt request.

ja, de henter siden, retter og opdatere. Men det er ikke et problem, de data som de retter kan ikke blive hentet eller rettet af andre, da dette kræver et login. Men det var mere i modellaget at jeg ikke ved om variablerne og objekterne kan "gå i hinanden".... Når man kalder en metode via corba bliver der automatisk oprettet en tråd, er dette også tilfældet her med jsp kald....??

Ja.

JSP/sevlet engine/container'eren:
  - compiler din JSP side til en servlet første gang den bruges
  - instantierer et objekt første gang den bruges (og kalder init metoden)
  - for hver request der kommer kaldes service metoden (for JSP: "siden")
    i en tråd
  - engine/container har en eller anden restriktion på antal samtidige
    tråde den vil lave

Så det kan godt være nødvendigt at synchrionze.

Bemærk du kan godt bede om at få en JSP side gjort single-threaded,
men jeg formoder at performance ryger direkte til rotterne.

ja, men det er ikke så meget der skal synknronisret, så det bliver vidst ikke noget problem....

Jeg skal lige uddybe min sidste bemærkning.

Performance overhead ved at putte noget synchronized ind entenm i selve
JSP siden eller i klasser brugt af JSP siden vil ofte være minimal.

Det er performance overhead ved at erklære hele siden som single threaded
jeg frygter vil være voldsomt.