Paul,
The whole stack is stored in a property - with the same name as the
stack.
Therefore you are correct you need to use the property pattern to
retrieve the stack value.
You can use %P{OrderID} or %property{OrderID} in the PatternLayout.
Nicko
> -----Original Message-----
> From: Paul Welter [mailto:[EMAIL PROTECTED]
> Sent: 24 November 2004 16:30
> To: Log4NET User
> Subject: Re: LogicalThreadContext vs ThreadContext
>
> Thanks for the explination. I have another question now.
> When using the ThreadContext.Stacks, what pattern conversion
> character do you use to read it? Is it stored in the
> properties collection? For example ...
>
> using(ThreadContext.Stacks["OrderID"].Push(orderId))
> {
> // The above message will be attached to the stack for all
> // nested method calls made here
> }
>
> would it be ...
>
> %P{OrderID}
>
> or
>
> %x{OrderID}
>
> thank,
> Paul
>
>
> ----- Original Message -----
> From: "Nicko Cadell" <[EMAIL PROTECTED]>
> To: "Log4NET User" <[email protected]>
> Sent: Wednesday, November 24, 2004 9:45 AM
> Subject: RE: LogicalThreadContext vs ThreadContext
>
>
> Paul,
>
> The ThreadContext stores data in a thread local slot. This is attached
> to a specific runtime thread. In v1.0 and v1.1 this thread corresponds
> to an OS thread. The ThreadContext data is limited to that one thread
> and not visible from other threads.
>
> The LogicalThreadContext stores its data in a CallContext slot.
> For more info on CallContext see:
> http://msdn.microsoft.com/library/default.asp?url=/library/en-
> us/cpref/h
> tml/frlrfsystemruntimeremotingmessagingcallcontextclasstopic.asp
> The CallContext data is essentially data stored local to the logical
> thread. The logical thread can jump from one runtime thread
> to another.
> Other than that the behaviour will be the same as for the
> ThreadContext.
> In practice the LogicalThreadContext will behave nearly identically to
> the ThreadContext because we do not allow our
> LogicalThreadContext data
> to cross a remoting boundary (we do not implement the
> ILogicalThreadAffinative interface). As far as I know the only places
> where the LogicalThreadContext will transfer the data to
> another thread
> is for asynchronous delegate invocations which might execute on a
> different thread (but not ThreadPool.QueueUserWorkItem).
>
> > What is a CallContext, is that a method call?
>
> No it is the logical thread of execution not the current method call.
>
>
> > I would expect the values I set in a method
> > using LogicalThreadContext to go out of scope when the
> > execution leaves that method but it does not. Any ideas?
>
> Values attached to the CallContext remain in scope during the rest of
> the execution of the logical thread.
>
> If you want to set a value for the duration of a method call
> you should
> use a ThreadContext stack:
>
> // Push a message onto the stack for this
> using(ThreadContext.Stacks["NDC"].Push("my context message"))
> {
> // The above message will be attached to the stack for all
> // nested method calls made here
> }
> // at the end of the using block the message is automatically popped
>
>
> Hope that helps,
>
> Nicko
>
>
> PS. For those wondering the ThreadContext and LogicalThreadContext are
> only available in the CVS version of the log4net code.
>
> > -----Original Message-----
> > From: Paul Welter [mailto:[EMAIL PROTECTED]
> > Sent: 23 November 2004 20:25
> > To: [email protected]
> > Subject: LogicalThreadContext vs ThreadContext
> >
> > I'm a little confused as to the difference between
> > LogicalThreadContext and ThreadContext. Can someone explain
> > the difference? LogicalThreadContext says it is for
> > CallContext debugging. What is a CallContext, is that a
> > method call? I would expect the values I set in a method
> > using LogicalThreadContext to go out of scope when the
> > execution leaves that method but it does not. Any ideas?
> >
> > thanks
> > ~ Paul
> >
>
>
