Dropwizard @Timed Metric Interaction with Hibernate Paginated Queries

Developers want to measure the time spent executing the paginated Hibernate query separately from any post‑processing work (e.g., JSON serialization) that occurs after the query returns in a Dropwizard resource method annotated with @UnitOfWork. The @Timed annotation currently wraps the entire method, so the recorded metric conflates database fetch time with serialization, making it difficult to identify performance bottlenecks in large‑offset pagination.

Because the Hibernate Session is bound to the request scope by @UnitOfWork and is closed automatically after the method returns, any manual timing must be performed inside the method without interfering with the transaction boundary. It is unclear whether Dropwizard provides a nested metric mechanism or if developers should manually instantiate a Timer.Context to isolate the query execution while preserving the unit‑of‑work semantics.

Can a Timer.Context be started and stopped within the @UnitOfWork method to record a separate metric for the Hibernate query without affecting the outer @Timed measurement? If so, what is the recommended naming convention for the inner metric to distinguish it from the outer method timer? Are there any Dropwizard‑provided utilities or annotations that allow scoped timing of specific code blocks inside a @UnitOfWork‑managed method?