b2aat6n

Listing 4
Ein Update überprüfen.
[TestFixture]
public class ProductRepositoryTests
{
private ProduktRepository sut;
[SetUp]
public void Setup() {
sut = new ProduktRepository();
}
}
[Test]
public void Ein_Produkt_ändern() {
var produkt = new Produkt {
Id = "#1",
Name = "iPad",
Kategorie = "Zeugs"
};
sut.Save(produkt);
produkt.Kategorie = "Gadget";
sut.Save(produkt);
}
var result = sut.Load("#1");
Assert.That(result.Kategorie,
Is.EqualTo("Gadget"));
schende Objekt übergeben wird. Dabei
stellte sich mir die Frage, wie man ein Dokument
aus der Datenbank löscht, dessen
Id man kennt, das aber nicht als Objekt geladen
wurde. Natürlich kann man das Objekt
zuerst über seine Id laden, um es dann
an Delete zu übergeben. Dabei fallen aber
zwei Zugriffe auf den Server an, das sollte
doch auch mit einem Zugriff zu machen
sein. Das Löschen über die Id ist im Client-
API nicht vorgesehen. Das bedeutet aber
nicht, dass es unmöglich ist. Das Client-API
ist nur ein Wrapper, der über das HTTP-
Protokoll gelegt ist, und in diesem API ist
Löschen per Id nicht vorgesehen. Wie man
das API erweitert, habe ich mir allerdings
in diesem Spike nicht weiter angesehen.
Konkurrierende Zugriffe
Beim Erforschen des APIs ist mir an dieser
Stelle die Frage gekommen, wie RavenDB
sich bei konkurrierenden Zugriffen verhält.
Damit meine ich Zugriffe, die in zwei unterschiedlichen
Sessions stattfinden. Stellen
Sie sich dazu eine Anwendung vor, von der
mehrere Instanzen laufen. Was passiert,
wenn ein Dokument aus der Datenbank von
beiden Anwendern geladen und verändert
wird. Merkt RavenDB das beim Update? Um
die Frage zu klären, habe ich einen Test geschrieben.
Um dabei mit zwei Sessions ar-
beiten zu können, habe ich die Sessions ineinandergeschachtelt.
Das heißt, während
die erste Session noch aktiv ist, wird innerhalb
des using-Blocks eine zweite Session
geöffnet, um dort ein Update vorzunehmen.
Dann wird aus der ersten Session
ebenfalls ein Update abgesetzt.
Listing 5
Das Repository implementieren.
Das Verhalten von RavenDB hängt an
dieser Stelle davon ab, ob die Session Optimistic
Concurrency unterstützen soll. Dies
kann man per Session einstellen, standardmäßig
ist es abgestellt. Das bedeutet, wenn
man keine weitere Vorkehrung trifft, werden
Konflikte bei konkurrierenden Zugrif-
public class ProduktRepository {
private readonly DocumentStore store;
public ProduktRepository() {
store = new DocumentStore {Url = "http://localhost:8080"};
store.Initialize();
}
public void Save(Produkt produkt) {
using (var session = store.OpenSession()) {
session.Store(produkt);
session.SaveChanges();
}
}
public Produkt Load(string id) {
using (var session = store.OpenSession()) {
var result = session.Load(id);
return result;
}
}
}
Listing 6
Konkurrierende Zugriffe erkennen.
[Test]
public void Optimistic_Concurrency_bei_Updates_in_mehreren_Sessions() {
var store = new DocumentStore {Url = "http://localhost:8080"};
store.Initialize();
// Initialzustand der Datenbank herstellen
var produkt = new Produkt {Name = "a"};
using (var session = store.OpenSession()) {
session.Store(produkt);
session.SaveChanges();
}
// Erste Session lädt das Dokument als 'referenz1'
using (var session1 = store.OpenSession()) {
session1.UseOptimisticConcurrency = true;
var referenz1 = session1.Load(produkt.Id);
// Zweite Session lädt das Dokument als 'referenz2'
// und modifiziert es
using (var session2 = store.OpenSession()) {
var referenz2 = session2.Load(produkt.Id);
Assert.That(referenz2, Is.Not.SameAs(referenz1));
referenz2.Name = "b";
session2.SaveChanges();
}
// 'referenz1' hat die Änderungen aus der zweiten
// Session noch nicht gesehen, daher Bumm!
referenz1.Name = "c";
Assert.Throws(session1.SaveChanges);
}
}
LÖSUNG
www.dotnetpro.de dotnetpro.dojos.2011 35