---
title: 'Session-Verwaltung in Servlets mit HttpSession'
url: 'https://tutego.de/blog/javainsel/2013/09/session-verwaltung-in-servlets-mit-httpsession'
markdown: 'https://tutego.de/blog/javainsel/2013/09/session-verwaltung-in-servlets-mit-httpsession.md'
date: '2013-09-24'
description: 'Die Servlet-API bietet die Klasse HttpSession an, eine Bibliothek auf hohem Niveau für die Verwaltung einer Sitzung. Sie basiert entweder auf Cookies oder URL-Rewriting, doch wird das von der API transparent gehalten. Als Programmierer bekommen wir so gut wie gar nichts davon mit. Falls der Client …'
taxonomy:
  category:
    - 'Java EE'
    - 'Web Frameworks'
---

# Session-Verwaltung in Servlets mit HttpSession

![Illustration einer tropischen Insel mit Palmen und einem hohen Berg](https://tutego.de/blog/javainsel/user/themes/tutego/images/insel-cover.jpg)# Java Blog für Programmierer

[Java Blog für Programmierer](https://tutego.de/blog/javainsel/)

## Session-Verwaltung in Servlets mit HttpSession

24.09.2013 · [Christian Ullenboom](https://tutego.de/blog/javainsel/author/admin/)

Die Servlet-API bietet die Klasse HttpSession an, eine Bibliothek auf hohem Niveau für die Verwaltung einer Sitzung. Sie basiert entweder auf Cookies oder `URL`-Rewriting, doch wird das von der API transparent gehalten. Als Programmierer bekommen wir so gut wie gar nichts davon mit. Falls der Client keine Kekse mag, wandeln wir alle Informationen in URLs um, die wir dann anbieten. Ein Sitzungsobjekt verwaltet die gesicherten Daten auch selbstständig in einer Datenstruktur. Hier fällt für uns keine Arbeit an.

### Das mit einer Sitzung verbundene Objekt HttpSession

Jede Sitzung ist mit einem Sitzungsobjekt verbunden, das die Klasse HttpSession abbildet. Bei JSPs repräsentiert das implizite Objekt session die aktuelle Sitzung.

#### Werte mit einer Sitzung assoziieren und auslesen

Um Informationen mit der Sitzung zu verbinden, verwenden wir die Methode `setAttribute()`, die einen Schlüssel und einen Wert verbindet. Daten werden mit `getAttribute()` wieder aus der Datenstruktur gelockt, so wie es das folgende Beispiel zeigt:

```java
List l = (List) session.getAttribute( "artikel" );
```

Hier verbinden wir mit einem Schlüssel eine Liste von Waren. Im Hintergrund werden die Informationen auf der Serverseite gesichert. Die Informationen selbst werden nicht in Cookies oder in der `URL` abgelegt, daher spielt die Größe der Daten auch keine Rolle. Ein HttpSession-Objekt verwaltet einen Assoziativspeicher, der die Wertepaare speichert. Es ist günstig, die Elemente serialisierbar zu gestalten, um die Daten dauerhaft zu speichern.

Werfen wir abschließend einen Blick auf das Programmstück, das eine neue Ware hinzufügt:

```java
List l = (List) session.getAttribute( "artikel" );
if ( l == null )
{
  l = new ArrayList();
  session.setAttribute( "artikel", l );
}
l.add( w );
```

**interface `javax.servlet.http.HttpSession`**

- `Object getAttribute( String name )`

    Liefert das mit name verbundene Objekt; null, wenn es keine Assoziation gab.
- `Enumeration getAttributeNames()`

    Liefert eine Aufzählung aller mit der Sitzung verbundenen Objekte.
- `void setAttribute( String name, Object value )`

    Bindet name mit dem Objekt value an die Sitzung. Existierte das Objekt, wird es ersetzt. Angemeldete HttpSessionBindingListener werden über die Methode value Bound() beziehungsweise valueUnbound() informiert.
- `void removeAttribute( String name )`

    Entfernt das Attribut von der Sitzung. Ungültige Namen werden ignoriert. HttpSession BindingListener werden durch Aufruf von valueUnbound() informiert.

Alle Methoden liefern eine `IllegalStateException`, wenn die Sitzung ungültig ist. Die Methoden `putValue()` und `setValue()` sind veraltet und wurden durch `setAttribute()` und `getAttribute()` ersetzt.

### `URL`-Rewriting

Das Session-Management sollte im Prinzip unabhängig von der technischen Umsetzung sein. Doch leider greift das Sitzungsmanagement beim `URL`-Rewriting schon sehr stark ein: Bei jedem Verweis auf eine neue Seite muss die `URL` entsprechend angepasst werden, weil die Sitzungs-ID mitgeschickt werden muss. Cookies verwalten die Sitzungs-ID völlig anders. Das bedeutet: Werden Cookies eingesetzt, ändert sich die `URL` nicht und jeder kann problemlos auf eine neue Seite verweisen. Nur beim `URL`-Rewriting muss an die `URL` eine Sitzungskennung angehängt werden.

Beispiel Eine `URL` für einen Cookie besitzt keine Sitzungskennung.

- <http://localhost/servlet/URLRewritingSession>

Mit `URL`-Rewriting sieht das dann etwa so aus:

- <http://localhost/servlet/URLRewritingSession;jsessionid=abcde234>

Wenn wir innerhalb eines Servlets auf eine andere generierte Seite verweisen wollen, haben wir eine `URL` vor uns, zu der wir verzweigen möchten. Die Servlet-API kümmert sich darum, an eine Benutzer-`URL` die Sitzungs-ID automatisch anzuhängen. Dazu dienen die HttpServletResponse-Methoden `encodeURL()` und `encodeRedirectURL()`.

Beispiel: Aufgrund einer Formularbestätigung soll auf eine JSP-Seite mit dem Namen validate.jsp verwiesen werden:

```text

```

Werden der Verweis und die Kodierung aus Versehen vergessen, ist dies das Ende der Sitzung. Ob eine Sitzung mit einem Cookie behandelt wird, lässt sich mit `isRequestedSessionIdFromCookie()` testen. Dann kann aufgrund einer Fallunterscheidung `encodeURL()` verwendet werden oder nicht. Allgemein ist es aber nicht schlecht, grundsätzlich alle Verweise innerhalb einer Webapplikation mit `encodeURL()` zu sichern. Im Fall von Cookies wird zwar keine Kennung angehängt, eine spätere Umstellung gestaltet sich aber einfacher, falls der Nutzer die Cookies einmal ausschaltet.

### Zusätzliche Informationen

Ein Sitzungsobjekt verwaltet neben den assoziierten Daten noch weitere Informationen. Jede Sitzung bekommt eine eindeutige ID, die sich mit `getId()` erfragen lässt. Ist die Sitzung neu und hat der Client noch nie eine Verbindung gehabt, gibt `isNew()` den Wert `true` zurück. Existiert dann die Sitzung, gibt `getCreationTime()` ein long zurück – kodiert sind wie üblich die vergangenen Millisekunden seit dem 1.1.1970 –, in dem sich das Erstellungsdatum erfragen lässt. Dagegen erfragt `getLastAccessedTime()` die Zeit, die seit dem letzten Zugriff durch den Client vergangen ist. Falls der Server die Informationen dauerhaft speichert und der Cookie nicht abläuft, erlaubt dies Meldungen der Art: »Schön, Sie nach zwei Wochen zum fünften Mal bei unserer Partnervermittlung wiederzusehen. Hat’s wieder nicht geklappt?«

### Das Ende der Sitzung

Eine Sitzung ist nicht automatisch unendlich lange gültig. Bei Cookies lässt sich der Gültigkeitszeitraum einstellen. Auch Sitzungsobjekte lassen sich in der Zeit anpassen. Die Methode `setMaxInactiveInterval()` setzt den Wert, wie lange eine Sitzung gültig ist. Ist der Wert negativ, zeigt er an, dass die Sitzung nicht automatisch beendet wird. Die entsprechende Methode `getMaxInactiveInterval()` liefert die Zeit in Sekunden, in der eine Sitzung gültig ist.

**interface `javax.servlet.http.HttpSession`**

- `long getCreationTime()`

    Gibt in Millisekunden ab dem 1.1.1970 an, wann die Sitzung eröffnet wurde.
- `String getId()`

    Liefert eine eindeutige Kennung, die die Sitzung identifiziert.
- `long getLastAccessedTime()`

    Gibt in Millisekunden ab dem 1.1.1970 zurück, wann der Client zum letzten Mal auf den Server zugegriffen hat.
- `int getMaxInactiveInterval()`
- `void setMaxInactiveInterval( int interval )`

    Liefert und setzt die Zeit, für die der Servlet-Container die Sitzung aufrechterhalten soll, bis sie ungültig wird.
- `boolean isNew()`

    Der Rückgabewert ist true, wenn die Sitzung neu ist.

**Beispiel** Zum Schluss wollen wir ein Programm formulieren, das alle diese Informationen auf einmal ausgibt.

```text

Session-ID:  
Erzeugt am:  
Letzter Zugriff:  
Ungültig in Minuten:  
Anzahl Zugriffe: 
```

Das Programm liefert beispielsweise folgende Ausgabe:

```text
Hallo, alter Freund!
ID: 91410050092487D9B5D0D2A7A3D0F072
Erzeugt am: Fri Jan 18 20:16:49 CET 2002
Letzter Zugriff: Fri Jan 18 20:23:33 CET 2002
Ungültig in Minuten: 30
Anzahl Zugriffe: 4
```

Die ID sieht bei jedem Server anders aus. Der Webserver von Sun erzeugt beispielsweise ganz andere Kennungen.

Kategorien: [Java EE](https://tutego.de/blog/javainsel/category/java-ee/), [Web Frameworks](https://tutego.de/blog/javainsel/category/web-frameworks/)

[← Alle Beiträge](https://tutego.de/blog/javainsel/)

---

## Navigation

- Previous: [Eine Sich-Selbst-Implementierung](https://tutego.de/blog/javainsel/2013/09/eine-sich-selbst-implementierung.md)
- Next: [JavaZone 2013: Javapocalypse, immer wieder ein Hingucker](https://tutego.de/blog/javainsel/2013/09/javazone-2013-javapocalypse-immer-wieder-ein-hingucker.md)
