client/server og flerbruger

Hvad bliver denne klient brugt til, og skal den holde på databasen i længere tid. Lidt flere information tak :)

Det du er i gang med er lidt transaktionsstyring, som er en vanskelig størrelse. Det man ønsker at sikre er at to processer kan editere data atomisk, konsistent, isoleret og persisterende, så der ikke kan opstå problemer.

I transaktionskontekst kan grænserne være i din kode, eller i databasen, men den skal være der alligevel. I ønsker at sikre, at en ikke kan editere, hvis en anden er begyndt. Blandt de muligheder, der umiddelbart er:
mark and error (Den i bruger)
Locking (shared/exclusive locking, 2phase locking etc.)(blokerende kald).
Optimisk locking (som f.eks. Oracle anvender default).

Hvis i anvender en database, kan I spekulere i transaction isolation level. Hvis den er sat til serializable, vil to transaktioner blive serialiseret (altså ingen læsning før en update er committed).

Men, hvis det jeg formoder i jeres scenario er, at jeres transaktionsvindue er meget stort, at I læser om i kan editere før i i det hele taget påbegynder editeringen, så er jeres egen løsning noget nær den eneste brugbare. At lave deciderede transaktioner på tværs af en brugerinteraktion er noget nær idoti, så hvad det angår er der ingen nemme løsninger.

Normalt ville man lade flere brugere kunne editere samtidig, og kun sikre sig under opdateringer om der er problemer. Simpelthen fordi det er så få situationer, at det er nødvendigt.

Append til Logicals svar ))

Transaktionsstyrring, bliver det ikke ordnet på DBMS-niveau (altså -out-of-reach- for et JAVA-program...

Jeg kan ikke se, hvordan man løser dit problem udover den TSL-løsning, som du arbejder med i øjeblikket (den klodsede attribut)...

/Søren Munk Skrøder

bearhugx > En transaktion er nødvendigvis ikke en databasetransaktion, men en transaktion defineret af ens logik.

Hvis ens logik påkræver at man læser noget data fra en db, og en bruger redigerer, og derefter skal gemme data igen, så vil dette være transaktionen.

I dette tilfælde vil en logisk transaktion bestå af flere db transaktioner.

lbhansen >>
Jeg ved udenmærket godt, hvad en (DB)-transaktion er... Skal op i eksamen i det (teknologi) i overmorgen (onsdag)... Gruer for det...:-)

Det er ikke det jeg mente ...
Mit indlæg drejede sig om, hvorvidt man kunne påvirke denne transaktionsstyrring via JAVA (the category in question) ... Jeg kender ikke nogle eksempler, hvor man i en database, via JAVA, kan gå ind og sætte granularitetspolitik...

FaceOrbit >> Måske kunne det hjælpe, hvis vi vidste, hvilken DB du bruger (Access, SyBase, Oracle, MySQL, PostgreSQL ol.)

/Søren Munk Skrøder

bearhugx. Jammen så havde vi da lige snakket forbi hinanden.

Held og lykke med eksamen:)

thats ok... og tak for held+lykke ... (jeg tror jeg har brug for det :-)
Skal op til 4 eksamner i år --- de 3 kan jeg \'spadsere\' igennem, men Teknologi-eksamen (Operativsystemer, Netværk og Database) glæder jeg mig ikke til... (håber dog, at jeg trækker et OS spørgsmål... Det er der, jeg er stærkest :-)

/Søren Munk SKrøder

Transaktionsstyring kan ske med særligt transaktionssoftware, som typisk implementerer interfaces fra javax.transaction (j2ee), men transaktionsstyring kan man skrive selv. Det kan man iøvrigt med alt :-)

Held og lykke...Jeg mindes stadig de dage, hvor jeg sad på den anden side af bordet og evaluerede sine studerende :-)

Ja det kan vi andre også godt huske. Jeg tror bare vi sad på to forskellige sider:)

Mange gode hints indtil videre :)

qzus: Vi bruger en Oracle db, men skal migrere til Informix.
Scenariet er typisk at en bruger har det primære ansvar
for at behandle data vdr. en kunde aftale. Der kan imidlertid
være andre processer der involvere ændring af kundens
stamdata. De kan sagtens være sideløbende med den primære vedligeholdelse.

Der må kun være en forekomst af data i systemet. 2 brugere må altså ikke
kunne sidde med forskellige versioner af en kunde. Typisk kan behandlingen
af en kunde tage op til 1 time -> at kunden er låst i det tidsinterval.
Samtidig har man på brugersiden oplevet en del system crash (blå skærm)
hvilket har gjort at der er gået ged i \'låse systemet\', der er kodet på
client\'en. Derfor har man implementeret et \'låse administrations system\'
hvor en superbruger tildeles rettigheder til at fjerne låse i db. Et ansvar
man gerne vil være fri for. Derfor ledte (leder?) jeg efter en anden løsning/
gode ideer fra alle eksperterne.

En mulighed i distribuerede systemer (CORBA eller RMI). Lad dine opdateringer ske igennem en fælles stub i serveren, og implementer et observer pattern på den, så kan alle notificeres når der sker noget.

Din server skal selvfølgelig have 3-4 metoder:
addKundeListener(KundeListener);
removeKundeListener(KundeListener);
fireKundeDataChanged(KundeEvent ke);
updateKunde(KundeData kd);

(Get the picture :-) Det er lidt tungt med callback i rmi/corba, men absolut en god løsning. Så registrerer man sig inden man begynder at arbejde på kunden, hvis der kommer events undervejs, indlæser man de nye værdier (evt. i samarbejde med brugeren), og når man er færdig fjerner man sig selv.

Glemte lige en detalje...

Selv om en updateKunde() er synkron, serialiseret etc. kan der godt opstå nogle race conditions. Til at undgå det, så brug et optismisk log pattern.
Når man går igang med at arbejde med en kunde læser man en timestamp fra DB (last modified time). Denne sender man med til updateKunde. Hvis DB har en senere last modified time, bør man lave rollback, ellers update man db, og genererer en ny timestamp (som man sender med up i fireKundeDataChanged()).
Så burde der ikke være nogle problemer overhovedet.