[Mono-dev] WCF: InstanceContextMode.PerSession
atsushieno at veritas-vos-liberabit.com
Tue Jan 11 05:57:29 EST 2011
Ah, thanks, forgot about that ReleaseInstanceMode property ;-)
(2011/01/11 19:17), Adar Wesley wrote:
> I was reading this thread and just by chance was reading up on WCF
> Services Session instantiation and release today.
> I thought the following links might be useful to clear up the MS.NET
> <http://MS.NET> behavior:
> Sessions, Instancing, and Concurrency
> Hope this helps.
> Adar Wesley
> On Tue, Jan 11, 2011 at 8:07 AM, Atsushi Eno
> <atsushieno at veritas-vos-liberabit.com
> <mailto:atsushieno at veritas-vos-liberabit.com>> wrote:
> Hi again,
> To my understanding, a session (ISession) is usually member of
> ISessionChannel types, its lifecycle is bound to the channel, and we
> indeed have such implementation in TcpDuplexSessionChannel.
> If we got to know .NET behaviors we'll do the same in WCF ;)
> Atsushi Eno
> (2011/01/10 0:03), Karsten Fourmont wrote:
> > sigh: it seems no matter how long I wait before making a post to get
> > the details right, still every time something comes up minutes
> after I
> > hit the "send" button.
> > So here's a small addition:
> > It doesn't seem very well defined in the WCF documentation if an
> > Dispose should be called on a service instance. Service classes
> > have to be IDisposable. But if they are, .NET invokes Dispose and I
> > think mono should do the same. However exactly "when" this
> dispose is
> > supposed to happen is not perfectly clear:
> > http://msdn.microsoft.com/en-us/library/ms733040.aspx states:
> > "In the default case, WCF recycles the service object and its
> > after the session with which the service was associated is closed."
> > So Dispose doesn't have to be called on session termination, but
> > (maybe?) on service channel termination on the server side.
> > The service instance just has to be able to find out when it should
> > free the session's resources once the session is closed either
> by the
> > client or by the server (like due to an inactivity timeout).
> > Atsushi, I definitely don't envy you (or any of the mono team) for
> > having to implement something which is not properly specified. Only
> > Perl's "the implementation is the specification" seems worse ;-)
> > Great work!
> > Cheers,
> > Karsten
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> <mailto:Mono-devel-list at lists.ximian.com>
More information about the Mono-devel-list