De 10 vigtigste open source-projekter

kasperd (50) skrev:

Posix burde have et reexec signal man bare kunne sende til alle processer for at fortælle dem, at de skal reexec sig selv for at opdateringer tager effekt.

Eller man kunne genstarte maskinen...

kasperd (50) skrev:

. Og Mac OS X siger at de mest latterlige ting kræver en genstart, f.eks. kræves der vist en genstart bare fordi man har installeret nye video codex.

Man kan jo spørge sig selv hvorfor det er påkrævet på OSX og ikke på andre systemer.

Apple har jo med OSX gjort en *nix distro mainstream på blot få år, noget GNU/FSF ikke kunne gøre på 2 årtier.

Så ja, jeg vil stille spørgsmål om der ikke kunne være en god grund til at Mac kræver genstart.

#51

Der er ingen gode grunde til det, udover at udviklerne ikke prioriterer det, givetvist fordi få kunder prioriterer det. Men gode teknisk årsager? Jeg tror du skal lede længe.

#50

Tror du ramte plet, fra Postgresql's dokumentation om netop transaction isolation.

http://www.postgresql.org/docs/7.4/static/transact...

The Serializable mode provides a rigorous guarantee that each transaction sees a wholly consistent view of the database. However, the application has to be prepared to retry transactions when concurrent updates make it impossible to sustain the illusion of serial execution. Since the cost of redoing complex transactions may be significant, this mode is recommended only when updating transactions contain logic sufficiently complex that they may give wrong answers in Read Committed mode. Most commonly, Serializable mode is necessary when a transaction executes several successive commands that must see identical views of the database.

SmackedFly (46) skrev:

Nu er transaction isolation level serializable en optional feature. Du skal specifikt angive at din transaktion skal bruge det. Men sandt nok, hvis du bruger den bliver dine reads nødt til at vente på dine writes.

Men altså, min påstand var at postgresql ikke lader writes blokere reads, din helt rigtige modpåstand er at hvis du essentielt beder databasen om at serialisere alle transaktioner så gør den det, og så kan den selvfølgelig ikke undgå det... Fair nok, ingen diskution der.

aldrig != ikke default

SmackedFly (46) skrev:

Min pointe var egentligt bare at MySQL mangler locking features, og at postgresql kan være en løsning i de situationer.

Stort set alle andre databaser end MySQL MyISAM supporterer transaktioner og har dermed også nogle mere avancerede locking mekanismer.

Hvis man har det behov med MySQL bruger man InnoDB. Som har ca. de samme features på dette område som all andre.

kasperd (47) skrev:

Vis os det sted i standarden der siger, at sådan en transaktion aldrig kan fejle. Eftersom det er umuligt at implementere transaktioner på en måde, hvor de aldrig fejler, så tror jeg ikke standarden siger det.

Selvfølgelig kan transaktioner fejle.

Men der er forskel på at fejle p.g.a. eksterne forhold og så på at fejle som led i at løse det problem som de eksisterer for at løse.

kasperd (47) skrev:

Den semantik du påstår serializable transaktioner har betyder at det aldrig kan lade sig gøre for serveren at udføre to parallelt, uanset hvad de foretager sig.

Ikke korrekt.

To transaktioner som kører i transaction isolation levels erializable kan sagtens køre paralllelt, hvis de ikke arbejder på de samme data.

De kan ikke hvis de arbejder på de samme data. Det er normalt grunden til at vælge så højt et level.

kasperd (47) skrev:

Hvis den første transaktion har læst noget fra tabel A og den anden transaktion har læst noget fra tabel B, så kan serveren ikke garantere, at de aldrig kan nå i en situation, hvor den ene transaktion vil fejl. Den kan ikke vide, om de en gang senere i transaktionerne beslutter sig for at ændre de værdier hinanden har læst.

Hvorfor en typisk implementation vil udtage låse på det andre transaktioner ikke må ændre på.

kasperd (47) skrev:

Man kan selvfølgelig implementere det, så man aldrig kører mere end en af den slags transaktioner ad gangen. Men hvis man implementerer det på den måde, så gør man jo hver eneste serializable transaktion til et DoS angreb på sin database.

1) Se ovenfor omkring at det kun er ved tilgang til samme data at der serialiseres.

2) Transaktioner timer ud, så det er et meget kortvarigt DoS angreb.

kasperd (47) skrev:

(Hvis netforbindelsen mellem klient og server forsvinder eller serveren genstarter vil transaktioner fejle, med mindre koden på klientsiden kan genoprette forbindelsen. Og hvis databasen faktisk gemmer nok data til at klienten kan reconnecte efter det, så har du et andet problem, hvis en klient går ned. Serveren kan ikke vide, om det bare er en midlertidig netværksglitch, og derfor er den nødt til at bevare den tilstand for evigt).

kasperd (47) skrev:

Og hvis nu en klient går ned uden at lukke sin transaktion, så kan man aldrig mere udføre opdateringer på sin database, for det kunne jo være klienten engang kom tilbage, og i så fald må transaktionen ikke fejle.

Transaktioner timer ud.

kasperd (47) skrev:

Kort sagt. Databaseklienter er nødt til at kunne håndtere at en transaktion fejler, og prøve igen. Du kan forsøge at reducere hyppigheden af fejlende transaktioner, men du kan aldrig forhindre dem helt.

Helt korrekt.

Applikationen skal kunne håndtere situationer med transaction timeouts, deadlocks, netværk glitches etc..

Men det er noget andet end at håndtere concurrency som trabsaction isolation level skulle håndtere.

#55

Men det lyder nu iøvrigt som om at Oracle og PostgreSQL faktisk gør som du beskriver.

http://en.wikipedia.org/wiki/Transaction_isolation... siger:

This isolation level specifies that all transactions occur in a completely isolated fashion; i.e., as if all transactions in the system had executed serially, one after the other. The DBMS may execute two or more transactions at the same time only if the illusion of serial execution can be maintained. At this isolation level, phantom reads cannot occur.

However, many databases (e.g. Oracle[1], PostgreSQL[2]) do not guarantee that there is some serial ordering of the transactions that will result in the same outcome, instead implementing snapshot isolation. This explicitly contradicts the ANSI/ISO SQL 99 standard (see ISO/IEC9075-2:1999(E), page 83). Other databases (MS SQL Server[3]) support both serializable and snapshot isolation modes.

With a lock-based concurrency control DBMS implementation, serializability requires that range locks are acquired when a query uses a ranged WHERE clause. When using non-lock concurrency control, no lock is acquired; however, if the system detects a concurrent transaction in progress which would violate the serializability illusion, it must force that transaction to roll back, and the application will have to restart the transaction.

SmackedFly (52) skrev:

Men gode teknisk årsager?

Stabilitet kan være en teknisk årsag.

At genstarte alle services på en maskine, mens brugeren benytter den, f.eks. spiller et spil, vil uundgåeligt påvirke den performance brugeren mærker til !

Derudover kunne jeg sagtes forestille mig software crash hvis ting ikke blev sat i kø korrekt. Så ja, stabilitet.

#57

Det er jo en implementations detalje, det kan jeg ikke se som et fornuftigt argument.

Hvis du bruger maskinen til en process som skal bruge næsten alle systemressourcer så lader du vel heller ikke maskinen opdatere samtidig.