-
Notifications
You must be signed in to change notification settings - Fork 1.4k
Description
In Orchard CMS 1.x, during shell startup — particularly during the Activate() phase — route registration logic often performs database access using IRepository. For example, the AliasStorage class queries the alias table via IRepository to dynamically generate routes.
This access appears successful, but it causes a critical problem later during session resolution.
Flow and Root Cause:
-
Activate() get invoked
-
Route providers (e.g., IRouteProvider, IHttpRouteProvider) are resolved.
-
During route setup, some (like AliasStorage) access the database using IRepository.
-
This database access causes ISession to be initialized internally via ITransactionManager.
-
After this, the following block runs:
using (var scope = _workContextAccessor.CreateWorkContextScope()) { using (var events = scope.Resolve<Owned<IOrchardShellEvents>>()) { events.Value.Activated(); } }
-
Inside it invokes Activated which will try to get the session.
-
However, the session that was initialised before the above code block was not reused in this subsequent scopes — even when using CreateWorkContextScope() correctly.
Instead, any new resolution of ISession or ITransactionManager.GetSession() yields a fresh session instance, breaking the original session lifecycle.
Why This Is a Serious Problem:
Over time, these undisposed sessions lead to significant tempdb growth, causing performance degradation or system instability.
Summary of Impact:
The session becomes detached or null in post-routing resolutions.
Any logic that relies on ITransactionManager.GetSession() during or after shell startup receives a new, isolated session.
This disrupts Orchard's session scoping model and causes NHibernate resource leaks.
tempdb increases due to the accumulation of unclosed or unmanaged sessions.
Request:
Any guidance on how to safely access the database during shell startup — without breaking the session lifecycle or triggering session duplication — would be greatly appreciated.
Is there a supported way to preserve the same session across early shell activation logic and standard request scopes?
Thanks so much in advance!