You shouldn't dispose of child sessions. On Thu, Feb 25, 2010 at 2:08 AM, David Archer <[email protected]> wrote:
> The API docs for the ISession.GetSession(EntityMode) function state: > == > Starts a new Session with the given entity mode in effect. This > secondary Session inherits the connection, transaction, and other > context information from the primary Session. It doesn't need to be > flushed or closed by the developer. > == > > The current implementation doesn't always "start a new session" but > rather will only start a new session the first time you call > GetSession for a given entity mode. Subsequent calls to GetSession > with the same entity mode will return the same session that was > returned the first time. > > example > == > var rootSession = OpenSession(); > var childSession1 = rootSession.GetSession(EntityMode.Poco); > var childSession2 = rootSession.GetSession(EntityMode.Poco); > // childSession1 == childSession2 > == > > Currently, SessionImpl uses a Dictionary<EntityMode, ISession> to > track each new child session created. Given that session creation is > "cheap", is there any reason this couldn't be a List<ISession> and > always return a new Session? > > The use-case where this came up for me was where I had multiple event > listeners registered that needed to save additional entities to the > database and each were using GetSession to "create" a child session. > If I disposed/closed the child session in the first event listener, I > would get a "session is closed" error when the second event listener > ran because GetSession would return the already closed/disposed > session from the first event listener. I understand there are > workarounds I can do (use the session factory to create a new session > or don't close/dispose the child session) to avoid the error but it > still seems the implementation is out of line with the documentation. > > I'll be more than happy to open a JIRA ticket for this with a test > case but wanted to get some feedback here first. >
