on Thursday, September 4, 2008, 10:37:39 PM Edi wrote:
On Thu, 4 Sep 2008 06:47:38 +0200, "Hans Hübner" hans@huebner.org wrote:
I agree, this could be a problem if one session is accessed by multiple requests, and this is not a completely unlikely scenario (although I have not been bitten by this). Do you have a patch?
I don't think this needs a patch. There's a lock for the case that Hunchentoot accesses the global session database. If you (as a user) write an application where different handlers or different threads work on the same session object at the same time, then you know what you're doing and you should take care of locking (if needed) yourself. IMNSHO it is a bad decision to defensively wrap locks around everything that could in theory be accessed simultaneously.
Yes, such a contract may be used too, although in this case it looks to me that user must take care of locking in virtually 100% of cases - even single handler may be called from different threads for the same session. And btw this is unexpected clarification to session functions behavior, at least for me.
In fact my attention to this question was drawn by the fact that (SETF (SESSION-VALUE )) uses lock, but other functions do not. And the condition that aimed to be protected by the lock in (SETF (SESSION-VALUE )) may potentially be broken by concurrent DELETE-SESSION-VALUE.
Best regards, -Anton
P.S. If you wonder why am I poking in the hunchentoot code - I am studying how session keys are generated in hope to find an example of secure random value generation to use it in cl-openid.