What causes "Managed operations not supported" in quarkusio/quarkus?

Use getStatelessSession(entityClass) instead, which the stateless implementation does support

quarkusio/quarkus · error · UnsupportedOperationException

Managed operations not supported

Error message

Managed operations not supported

What it means

StatelessBlockingOperations backs operations with a StatelessSession, so there is no managed Session to return; getSession(Class) is intentionally unsupported (the source even carries a FIXME noting this is wrong). It always throws UnsupportedOperationException.

Source

Thrown at extensions/data/hibernate/runtime/src/main/java/io/quarkus/data/hibernate/runtime/orm/StatelessBlockingOperations.java:27

import org.hibernate.Session;
import org.hibernate.StatelessSession;

import io.quarkus.data.hibernate.blocking.BlockingDataQuery;
import io.quarkus.data.hibernate.runtime.spi.PanacheBlockingOperations;

public class StatelessBlockingOperations implements PanacheBlockingOperations {

    public final static StatelessBlockingOperations INSTANCE = new StatelessBlockingOperations();
    private final static StatelessBlockingJpaOperations DELEGATE = new StatelessBlockingJpaOperations();

    private StatelessBlockingOperations() {
    }

    @Override
    public Session getSession(Class<?> entityClass) {
        // FIXME: this is wrong
        throw new UnsupportedOperationException("Managed operations not supported");
    }

    @Override
    public StatelessSession getStatelessSession(Class<?> entityClass) {
        return DELEGATE.getSession(entityClass);
    }

    @Override
    public Void insert(Object entity) {
        DELEGATE.insert(entity);
        return null;
    }

    @Override
    public Void persist(Object entity) {
        throw new UnsupportedOperationException("Managed operations not supported");
    }

View on GitHub (pinned to e1c734241f)

Solutions

Use getStatelessSession(entityClass) instead, which the stateless implementation does support
Inject the managed Session/EntityManager separately via CDI when managed semantics are needed
Reconfigure that repository/persistence unit to managed mode if managed Session access is a hard requirement

Example fix

// before
Session s = operations.getSession(MyEntity.class);
// after
StatelessSession ss = operations.getStatelessSession(MyEntity.class);

Defensive patterns

Strategy: type-guard

Validate before calling

Class<? extends BlockingDataOperations<?>> opsClass = operations.getClass();
if (opsClass == StatelessBlockingOperations.class) {
    // use getStatelessSession instead of getSession
}

Type guard

boolean isStatelessOps(Object ops) {
    return ops instanceof StatelessBlockingOperations;
}

Try / catch

try {
    Session s = operations.getSession(entityClass);
} catch (UnsupportedOperationException e) {
    StatelessSession ss = operations.getStatelessSession(entityClass);
}

Prevention

Inject Session/StatelessSession directly via CDI instead of deriving one from operations
Keep managed and stateless code paths in separate repository classes
Search code for getSession() calls when enabling stateless mode

When it happens

Trigger: Calling getSession(entityClass) on an operations instance resolved in stateless mode (stateless persistence unit / repository configured for StatelessSession).

Common situations: Code that mixes managed Session APIs (queries, merge, refresh) with a repository wired to stateless sessions; framework internals resolving a session generically.

Related errors

AI-assisted analysis of quarkusio/quarkus@e1c734241f (2026-09-05). Data as JSON: /api/errors/81245019300af112. Report an issue: GitHub.