# HG changeset patch
# User Tom Gottfried <tom@intevation.de>
# Date 1425637296 -3600
# Node ID 5c53b7de04d96519f67bf99dc78ce9b28371a831
# Parent  321d6e50aebee6d7bbe129c6c780917b9637b0fa
The bug that motivated this extremely defensive error-handling was fixed in Rev fe7e9da6312a by nomore calling close() on a private variable.

diff -r 321d6e50aebe -r 5c53b7de04d9 backend/src/main/java/org/dive4elements/river/backend/SessionHolder.java
--- a/backend/src/main/java/org/dive4elements/river/backend/SessionHolder.java	Fri Mar 06 10:57:56 2015 +0100
+++ b/backend/src/main/java/org/dive4elements/river/backend/SessionHolder.java	Fri Mar 06 11:21:36 2015 +0100
@@ -50,23 +50,9 @@
         Session session = HOLDER.get();
         if (session != null) {
             log.debug("releasing session: " + session.hashCode());
-            try {
-                if (!session.isOpen()) {
-                    /* If this check really works in all cases why does hibernate
-                     * does not use it when you call close anyway. */
-                    log.debug("Session is not open. Calling close anyway.");
-                }
-                session.close();
-            } catch (Exception e) {
-                /* Do not try this at home. But hibernate may fail with an NPE
-                 * or any other exception depending on the state of the session.
-                 * According to doc this should only throw a HibernateException but
-                 * we definetely get NPE's here.
-                 */
-                log.error("Exception caught on session close! Session already closed?" + e.getMessage());
-            }
+            session.close();
         } else {
-            log.debug("release called on NULL session.");
+            log.error("release() called on NULL session.");
         }
         HOLDER.remove();
     }