No session currently bound to execution context - for query in authenticator

Trying to upgrade to dropwizard 0.9.0/1. I have a OauthAuthenticator registered that is trying to make a database query but getting the following error.

ERROR [2015-11-09 20:05:38,080] com.hometeamcare.apiserver.error.ThrowableMapper: Caught exception
! org.hibernate.HibernateException: No session currently bound to execution context
! at org.hibernate.context.internal.ManagedSessionContext.currentSession(ManagedSessionContext.java:75) ~[hibernate-core-4.3.11.Final.jar:4.3.11.Final]
! at org.hibernate.internal.SessionFactoryImpl.getCurrentSession(SessionFactoryImpl.java:1014) ~[hibernate-core-4.3.11.Final.jar:4.3.11.Final]
! at io.dropwizard.hibernate.AbstractDAO.currentSession(AbstractDAO.java:36) ~[dropwizard-hibernate-0.9.1.jar:0.9.1]
! at io.dropwizard.hibernate.AbstractDAO.get(AbstractDAO.java:134) ~[dropwizard-hibernate-0.9.1.jar:0.9.1]

I have the @UnitOfWork annotation on the resource method. (This works with dropwizard 0.8.x)

After spending a little time in the debugger it essentially looks like a session is never opened i.e this line is never called. https://github.com/dropwizard/dropwizard/blob/master/dropwizard-hibernate/src/main/java/io/dropwizard/hibernate/UnitOfWorkApplicationListener.java#L96

The event type never matches RESOURCE_METHOD_START (https://github.com/dropwizard/dropwizard/blob/master/dropwizard-hibernate/src/main/java/io/dropwizard/hibernate/UnitOfWorkApplicationListener.java#L81). The last event type triggered before it tries to go into the authenticator filters is REQUEST_MATCHED, and then it throws the exception.

[henryptung]

@arteam Should this really be closed? To me, having the Hibernate transaction not span both authentication and actual execution is actually a bug. There is an opening here where an account can be deleted between authentication and execution. This may or may not cause violation of invariants, but is at least an unexpected thing to worry about, and at worst could cause very subtle, but severe security holes (e.g. unintended reinsertion of an account object via cascading).

While supporting creation of sessions/transactions in multiple places is a mostly-works approach, I’m very worried that the illusion of one-transaction-per-request (which I think is the intent of the API) can be risky.

EDIT: To me, it makes a lot of sense to instead implement this using a paired ContainerRequest/ResponseFilter with high priority (< AUTHENTICATION); not sure though if that leaks resources in certain situations. It would, however, explicitly make the session and transaction span both method execution and filter processing, which I think is the fundamental thing of concern here.

[github-actions[bot]]

This issue is stale because it has been open 90 days with no activity. Remove stale label or comment or this will be closed in 14 days