08-02-2019, 01:46 AM
Hi Dan, I'm glad that I can answer it for a change :-)
I think they all can be answered at once:
- the Execute() method runs inside a lock (a high level lock applied at the collection - gSessions - level, not a session lock), so the UserSession is guaranteed to exist during the whole method. No other code will, for instance, just destroy that session and leave you with an access violation.
However, that lock is shared, not exclusive. This is good because even if your session is locked by some other code, you can still read it status (things that don't change or things that are safe to access even by multiple threads, e.g. the session ID). On the other hand, you are not free to do whatever you want with it, because other code might be using it at the same time.
So, bottom line is: treat it as any other object that needs to be read/written by multiple threads. Some properties are safe like LastAccess (which uses Interlocked* functions to handle it internally). Other boolean and 32bit numeric values might also be safe to read/write from multiple threads because they usually work atomically. But if you have objects or strings, then that's a different story. You need to use some form of protection there.
You have 2 options: Explicitly lock the session before reading/writing to it (which will lock the whole thing and might fail if the session is already locked) or you can implement a more granular lock (you can create a critical section for each session and lock it only when reading/writing certain properties). If what you intend to do runs very quickly, maybe you can start with the session lock and see if it works well. You can locking/unlocking as session is really *fast*. The only "if" there happens when the session is already locked. But you can try to lock it using a very low timeout value, so the code won't wait if the session is already locked.
Please let me know if you need some example
I think they all can be answered at once:
- the Execute() method runs inside a lock (a high level lock applied at the collection - gSessions - level, not a session lock), so the UserSession is guaranteed to exist during the whole method. No other code will, for instance, just destroy that session and leave you with an access violation.
However, that lock is shared, not exclusive. This is good because even if your session is locked by some other code, you can still read it status (things that don't change or things that are safe to access even by multiple threads, e.g. the session ID). On the other hand, you are not free to do whatever you want with it, because other code might be using it at the same time.
So, bottom line is: treat it as any other object that needs to be read/written by multiple threads. Some properties are safe like LastAccess (which uses Interlocked* functions to handle it internally). Other boolean and 32bit numeric values might also be safe to read/write from multiple threads because they usually work atomically. But if you have objects or strings, then that's a different story. You need to use some form of protection there.
You have 2 options: Explicitly lock the session before reading/writing to it (which will lock the whole thing and might fail if the session is already locked) or you can implement a more granular lock (you can create a critical section for each session and lock it only when reading/writing certain properties). If what you intend to do runs very quickly, maybe you can start with the session lock and see if it works well. You can locking/unlocking as session is really *fast*. The only "if" there happens when the session is already locked. But you can try to lock it using a very low timeout value, so the code won't wait if the session is already locked.
Please let me know if you need some example