Note that there are some explanatory texts on larger screens.

plurals
  1. POWSGI: making each request truly unique
    primarykey
    data
    text
    <p>I'm currently familiarizing myself with the WSGI specifications for web applications in Python. I set up Apache (with mod-wsgi) to call a small application that currently just displays the thread id number, in an attempt to observe the uniqueness of each request:</p> <pre><code>import thread def application(environ, start_response) start_response('200 Ok', [('Content-type', 'text/plain')]) output = "current thread id: %s" % thread.get_ident() return [output] </code></pre> <p>I soon noticed that after a little while, the same threads are being reused by subsequent requests. </p> <p>If my understanding is correct, in order for my application to have "context-specific" variables, I need to store them with a scheme similar to this: </p> <pre><code>lock = thread.allocate_lock() lock.acquire() thread_id = get_ident() threadsafe[thread_id]['user'] = request.username lock.release() </code></pre> <p>I can then access them from different part of the application in a similar fashion. The only guarantee that I have in this case is that the value belongs to that specific thread. However, requests using that same thread might still step on each other's toes (e.g. a request accessing left-over values from a previous request). My conclusion is that to handle each request in a truly unique fashion, in addition to the "thread_id", I'll need another key that can differentiate between requests that use the same thread.</p> <p>Using a unique key such as uuid, I could do this</p> <pre><code>lock.acquire() uuid = uuid.uuid4() thread_id = get_ident() threadsafe[(thread_id, uuid)]['user'] = request.username lock.release() </code></pre> <p>but this implies that I have a way to also retrieve the uuid value in a thread-safe way, the same way I can retrieve the thread_id later.</p> <p>Did I draw the right conclusions? If so, how do I get that additional key?</p> <p><strong>Edit</strong></p> <p>It just occured to me that my problem is a false dichotomy. I'm approaching things with the perspective that a thread could be running concurrently to itself, when in fact this is not possible. Requests using the same thread, would have to run in series. Therefore, I could actually use the uuid to avoid using the thread's stale values, but only after storing it as a thread-save value itself. </p> <pre><code># somewhere early in the request threadsafe[thread_id]['current_uuid'] = uuid.uuid4() # later lock.acquire() thread_id = get_ident() uuid = threadsafe[thread_id]['current_uuid'] threadsafe[(thread_id, uuid)]['user'] = request.username lock.release() </code></pre>
    singulars
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload