com.sun.faces.context.SessionMap.put(key, value)

Dieses Thema com.sun.faces.context.SessionMap.put(key, value) im Forum "Web Tier" wurde erstellt von rmacher01, 3. Sep. 2015.

Thema: com.sun.faces.context.SessionMap.put(key, value) >> WebApplikation, JSF 2.0 / JPA (EclipseLink) / Tomcat 8.x << Irgendwie bringe ich es nicht fertig, ein in Session...

  1. >> WebApplikation, JSF 2.0 / JPA (EclipseLink) / Tomcat 8.x <<

    Irgendwie bringe ich es nicht fertig, ein in Session verwaltetes Objekt mit put(key, newValue) zu ersetzten!

    Folgendes Szenario (JSF & JPA):
    • Eine in Session verwaltete Entity wird aus der Session geholt
    • die Entity wird danach updatet (Feld 'version' wird verwaltet --> optimistic locking)
    • eine Kontrolle ergibt, dass der Version-Wert der zurückgegebenen Entity um Eins erhöht wurde und somit um Eins höher als der Wert der in Session verwaltete Entity ist: Alles OK
    • jetzt wird die erhaltene Entity in Session geschrieben: FacesContext.getCurrentInstance().getExternalContext().getSessionMap().put("key", newEntity);
    Wenn ich die Entity wieder aus der Session hole

    MyEntity e = (MyEntity)FacesContext.getCurrentInstance().getExternalContext()
    .getSessionMap().get("key");


    und den Version-Wert anschaue, ist der Version-Wert unverändert geblieben (gleich wie vor dem put-Aufruf). Die Schlussfolgerung ist, dass die Entity nicht ersetzt wurde (wie dies bei einer Mappe der Fall sein sollte). Jede wetere Änderung auf der aus der Session neu geholte Entity (mit EntityManager) führt dazu, dass die OptimisticLockException geworfen wird.

    Wenn ich aber zuvor noch die Entity aus der Session entferne, dann funktioniert es:

    FacesContext.getCurrentInstance().getExternalContext()
    .getSessionMap().remove("key");


    FacesContext.getCurrentInstance().getExternalContext()
    .getSessionMap().put("key", newEntity);


    Die Sessin-Map Klasse ist die Klasse com.sun.faces.context.SessionMap, die aber von java.util.AbstractMap<String, V> abgeleitet wird. Laut API-Doku müsste die Methode put das vorhandene value-Objekt mit dem neuen Objekt ersetzten. Aber, das ist die Theorie ...

    Mache ich hier einen Überlegungsfehler, oder woran kann es liegen?

    Vielen Dank
     
  2. Vielleicht helfen dir diese Java-Grundlagen weiter --> *Klick*
  3. stg
    stg
    Berücksichtigt deine equals-Methode das Version-Field? Beziehungweise die geänderten Attribute?

    Falls nein, dann hast du darin deine Antwort gefunden. Es gibt keinen Grund "gleiches" mit "gleichem" zu ersetzen. Da kann man sich die mitunter relativ teure Serialisierung sparen.

    Angeachtet dessen musst du dir doch auch eigentlich nur die Versionsnummer merken, nicht den ganzen Zustand?!
     
  4. Vielen Dank, genau das war es :mad:

    Ich war der Meinung, dass im Fall, dass für ein bestehendes Key ein neues Objekt kommt, das bestehende Objekt ohne wenn und aber ersetzt wird und eine Überprüfung auf Gelichkeit gar nicht durchgeführt wird. So habe ich an die Implementierung der Methode 'equals' gar nicht gedacht. Aber, da war ich halt auf dem Holzweg ... :oops:
     
    Zuletzt bearbeitet: 3. Sep. 2015
  5. KOSTENLOSES Java-Grundlagen Training im Wert von 39 € Sichere dir hier den kostenlosen Zugriff auf umfangreiches Java-Know How und starte richtig durch!