|
1 | 1 | using System;
|
| 2 | +using System.Threading; |
2 | 3 |
|
3 | 4 | namespace NHibernate.Impl
|
4 | 5 | {
|
5 | 6 | public class SessionIdLoggingContext : IDisposable
|
6 | 7 | {
|
7 |
| - [ThreadStatic] |
8 |
| - private static Guid? CurrentSessionId; |
| 8 | + private static readonly AsyncLocal<Guid?> _currentSessionId = new AsyncLocal<Guid?>(); |
9 | 9 |
|
10 |
| - private readonly Guid? oldSessonId; |
| 10 | + private readonly Guid? _oldSessonId; |
11 | 11 |
|
12 | 12 | public SessionIdLoggingContext(Guid id)
|
13 | 13 | {
|
14 |
| - oldSessonId = SessionId; |
| 14 | + _oldSessonId = SessionId; |
15 | 15 | SessionId = id;
|
16 | 16 | }
|
17 | 17 |
|
18 | 18 | /// <summary>
|
19 |
| - /// We always set the result to use a thread static variable, on the face of it, |
| 19 | + /// We always set the result to use an async local variable, on the face of it, |
20 | 20 | /// it looks like it is not a valid choice, since ASP.Net and WCF may decide to switch
|
21 | 21 | /// threads on us. But, since SessionIdLoggingContext is only used inside NH calls, and since
|
22 |
| - /// NH calls are never async, this isn't an issue for us. |
| 22 | + /// NH calls are either async-await or fully synchronous, this isn't an issue for us. |
23 | 23 | /// In addition to that, attempting to match to the current context has proven to be performance hit.
|
24 | 24 | /// </summary>
|
25 | 25 | public static Guid? SessionId
|
26 | 26 | {
|
27 |
| - get { return CurrentSessionId; } |
28 |
| - set { CurrentSessionId = value; } |
| 27 | + get => _currentSessionId.Value; |
| 28 | + set => _currentSessionId.Value = value; |
29 | 29 | }
|
30 | 30 |
|
31 | 31 | #region IDisposable Members
|
32 | 32 |
|
33 | 33 | public void Dispose()
|
34 | 34 | {
|
35 |
| - SessionId = oldSessonId; |
| 35 | + SessionId = _oldSessonId; |
36 | 36 | }
|
37 | 37 |
|
38 | 38 | #endregion
|
|
0 commit comments