could not initialize proxy - no Session when accessing lazy-loaded collection

Question

The goal is to lower CPU and memory consumption for a low‑traffic NHibernate‑based web or service application while preventing LazyInitializationException when lazy‑loaded collections are accessed after the session is closed.

Constraints include choosing appropriate second‑level cache regions and expiration policies, setting an AdoBatchSize that balances batch overhead with occasional bulk loads, deciding whether to use FlushMode.Commit or Auto, and determining when a StatelessSession is safe for read‑only reporting without introducing mapping or consistency issues.

What AdoBatchSize range yields the best trade‑off for infrequent bulk inserts/updates in a low‑traffic scenario? How should second‑level cache regions be sized and expired to avoid stale data while still reducing database round‑trips? When using StatelessSession for bulk read‑only operations, what precautions are needed to avoid missing properties or association loading problems?

Tasadduq Burney · Answer

Resolving LazyInitializationException
The LazyInitializationException occurs because NHibernate uses proxies for lazy-loaded collections. When the ISession is closed (typically at the end of a request or transaction), these proxies lose their connection to the database. Attempting to access them in a view or service layer after the session is disposed triggers the error.

Recommended Configuration for Low-Traffic Environments
To reduce CPU and memory overhead while maintaining stability, apply the following settings:

AdoBatchSize: For infrequent bulk operations, a range of 20 to 50 is generally the optimal trade-off. This reduces round-trips without consuming excessive memory or hitting database parameter limits.
  FlushMode: Use FlushMode.Commit. This prevents NHibernate from performing dirty checks and flushing changes to the database before every query, significantly reducing CPU cycles during read-heavy operations.
  Second-Level Cache (L2):
    
      Sizing: Use a small, fixed-size region for static reference data (e.g., Country codes, Categories).
      Expiration: Implement a Time-To-Live (TTL) of 12–24 hours for reference data. For volatile data, use a short TTL (e.g., 5–10 minutes) or avoid L2 caching entirely to prevent stale data.

Using StatelessSession for Read-Only Reporting
A IStatelessSession is highly efficient for bulk reads because it bypasses the first-level cache and dirty checking. However, it requires specific precautions:

Precaution
      Reasoning

Explicit Joins
      Stateless sessions do not support lazy loading. You must use Fetch or JoinQueryOver to load associations.

DTO Projection
      Project results directly into DTOs using Select to avoid issues with uninitialized proxies.

No Automatic Updates
      Changes to entities in a StatelessSession are not tracked; you must call Update() explicitly.

Verification Steps
To verify these changes, monitor the SQL output using a tool like NHibernate Profiler or by enabling show_sql. Ensure that bulk inserts are grouped into batches of your chosen AdoBatchSize and that reporting queries do not trigger subsequent "N+1" select statements.

Diagnostic Question: Are you using a specific L2 cache provider (e.g., SysCache, Redis), or are you relying on the default in-memory implementation?

Precaution	Reasoning
Explicit Joins	Stateless sessions do not support lazy loading. You must use `Fetch` or `JoinQueryOver` to load associations.
DTO Projection	Project results directly into DTOs using `Select` to avoid issues with uninitialized proxies.
No Automatic Updates	Changes to entities in a StatelessSession are not tracked; you must call `Update()` explicitly.

could not initialize proxy - no Session when accessing lazy-loaded collection

1 answer

Resolving LazyInitializationException

Recommended Configuration for Low-Traffic Environments

Using StatelessSession for Read-Only Reporting

Verification Steps

Your perspective belongs here.

1 question comment