Skalerbarhet i tradisjonell softwareutvikling innebærer ofte at man gjør seg mindre avhengig av databasen, og introduserer en objektcache i minnet til en eller flere servere. Problemer oppstår når dataene forandrer seg under skjørtene på serveren. Da kan man låne noen teknikker fra webben: HTTP har nemlig særdeles gode mekanismer for å kunne skalere.

Først må man akseptere at ikke alle nodene i en server vil til enhver tid se de aller siste dataene. Hvis du lager en børsapplikasjon som skal tjene penger på day-trading er det kanskje greit å ha de siste tallene, og ikke en 60 sekunder gammel kurs. Kan man akseptere litt elde (noen sekunder) er mulighetene mange.

Ok punkt en er å putte objektene inn i cache, men det er jo ikke så spennende. Noen ganger vet man at objektet forandrer seg et spesielt klokkeslett. Slikt kan man nytte seg av: Man tar HTTP’s Cache-Control: max-age og gjør noe tilsvarende med objektene når de puttes i en cache. Hvis man vet at objektet ikke er gyldig etter et visst klokkeslett er det bare å fortelle cache’n dette.

Hvis objektene fakisk brukes til videre oppdatering mot databasen (f.eks. du forandrer en liten ting og O/R mappingen tar og lagrer hele greia) så låner man If-Unmodified-Since eller enda bedre: If-Match fra HTTP og "gjør det selv. Når man får et objekt som skal sendes ned til databasen, så sjekker man versjonsnummeret til objektet man fikk er det samme som versjonsnummeret i databasen. Versjonsnummeret må selvfølgelig ikke være noe som klientkoden kan forandre på. Modifiseringsdato funker også om man ikke liker versjonsnummer.

Hva om dataene har forandret seg? Jo, det er jo HTTP 412 Precondition Failed som får en liknende vri i koden din. Slikt kan stort sett unngås ved å gjøre noe som tilsvarer en unconditional GET—nemlig å forbigå cachen når man henter data for oppdatering. Ingen kan garantere at andre holder seg unna dataene om ikke man har en form for pessimistisk lås da. Utrolig nok har ikke Wikipedia noen entry for Pessimistic locking, bare Optimistic locking.

Hvis objektene forandrer seg av ymse årsaker, så kan man låne mnot sin lovende Cache Channels slik: Med jevne mellomrom (et par ganger i minuttet) henter cachen ut en liste med endringer fra databasen, og fjerner så utdaterte objektene fra cachen. Finnes det flere cacher vil de alle hente samme liste med jevne mellomrom, og er det virkelig mange cacher kan jo listen over endringer caches den også.

Nettoresultat:

• Cachen kan holde på objekter i laang tid. Hvis dette er en memcached kan dette være gunstig :-)
• Cachen fjerner objekter som går ut på tid til riktig tid
• Cachen fjerner objekter som har forandret seg innen 30 sekunder, i snitt etter 15 sekunder (eller slik du konfigurerer)
• Oppdateringer på “gamle” objekter nektes, så man beholder dataintegritet
• Det skalerer: Du kan ha så mange cacher i systemet som du ønsker

Ganske stilig.

Motto? Les HTTP spec’en (igjen)!