26. januar 2006 - 16:18Der er
18 kommentarer og 1 løsning
Webservice concurrency
Hejsa
Jeg har kodet en Webservice i Java baseret på en Java Enterprise Bean, men jeg regner med at mit problem er lidt mere generelt.
I min webservice skal jeg oprette en fil som jeg skal være 100% sikker på har et unikt filnavn (ikke path).
i første omgang tænkte jeg at det måtte være rigeligt med en logisk nøgle efterfulgt af et timestamp i milisekunder. så min kode ser nogenlunde sådan her ud
while (destinationFile == null || destinationFile.exists()) { //file not created yet or a file with this name already exists //add the current time as suffix to ensure unique names fileName = consignmentNo + "_" + System.currentTimeMillis() + ".jpg";
destinationPath = smbPath + "/" + dir + "/" + fileName; destinationFile = new SmbFile(destinationPath); }
destinationFile.createNewFile();
min webservice skal køre på en server med flere CPU'er (8 tror jeg), så derfor kan jeg vel ikke være sikker på at to filer ikke får det samme navn hvis de to CPU'er eksekverer denne kode nøjagtig samtidig.
Mit spørgsmål er derfor todelt 1:hvad sker der egentlig når den samme metode i en webservice bliver kaldt flere gange? bliver der oprettet flere objecter af den underliggende Bean, startes der flere tråde som arbejder på det samme object?
2:afhængigt af svaret på 1 hvordan sikrer man sig et unikt id? jeg tænkte at det kunne være en kombination af timestamp og hashkey for det aktive object eller tråd.
Der må være utallige programmører der har haft dette problem før men jeg har ikke kunnet finde nogen best practice for webservice concurrency. Alle gode ideer værdsættes (og belønnes)
-> jakoba men så skal den vel være syncronized, for at være trådsikker? meget af min usikkerhed består i at jeg ikke rigtig ved hvordan Webservicen fungerer bag min ryg mht. flere samtidige kald
-> erik en static for hver process? nu er jeg ikke lige med på hvad du mener med flere processer, tråde instancer? min børnelærdom siger at når noget er statisk findes det kun en gang, men det kan selvfølgelig være en sandhed med modifikationer. Men hvis static ikke sikrer at alle instancer bruger den samme fortløbende variabel så er jeg jo lige vidt
Jeg siger netop processer, og ikke tråde. En webserver kan sagtens oprette et antal processer, hvori der så er et antal tråde i hver. Og bør vel typisk gøre det når der er flere CPU-er.
Og så vidt jeg husker JVM gælder static kun samme process - men de kan efterhånden så mange ting, så måske tager jeg fejl.
nu ved jeg ikke hvad du bruger som web service kit
men hvis det f.eks. er Axis saa kan du angive i din WSDD om der skal laves et objekt af web service klassen per request, per session eller per application (singleton)
jakobs teknik virker fint hvis: - der ikke behoever vaere unikness mellem genstart af serveren - det er en single node config og ikke en cluster config
ellers vil je anbefale Scott Ambler high low approach
jeg har været på ferie i en uge og det er derfor jeg ikke har vendt tilbage. ->erik jeg er stadig ikke helt med på hvad en process og en tråd er i denne sammenhæng
->arne web service kit må være SAP netweaver (en SAP udvidelse af Eclipse) men her mener du at man burde kunne sætte op hvor mange objecter der skabes osv? Scott Ambler high low approach??? øhh kan du sige mere?
vi har netop en cluster løsning og uniqueness skal gælde efter genstart, men dette burde kunne klares vha timestamp, som sagt har jeg kun et problem hvis 2 tråde/processer/instancer hvad det nu er behandler et request i samme milisekund, jeg kan ikke lige overskue hvoe sandsynligt det er men det kan vel ske
med web service kit mener jeg det som bruges paa serveren - ikke det som bruges til udvikling
i Axis kan kan man angive scope for objekterne for hver service i deployment descriptoren
du kan finde information om high low paa nettet - det grundliggend eprincip er at id'et bestaar af en high del og en low del, low delen fungerer ligesom jakobs counter, high delen fungerer via database
eksempel:
ved opstart laeser server_1 11 fra database og opdaterer til 12, server_2 laser 12 og opdatere til 13, server_1 bruger nu 11001 11002 11003 ... mens server_2 bruger 12001 12002 12003
server_2 genstartes ved 12897 og laser saa 13 og opdaterer til 14 og starter saa 13001 13002 13003 ...
server_1 naar derimod 11999 og laser saa 14 og opdaterer til 15 og koerer videre med 14001 14002 14003 ...
unikke vaerdier paa tvaers af cluster nodes og over genstart
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.
