[ZODB-Dev] Webkit Threading and ZODB 3.3a2: problems on Windows

[Tim Peters]

[Matt Feifarek]
>> The crucial subtlety is that a thread does NOT
>> destroy/garbage-collect its servlet instance after servicing the
>> request. Rather, the servlet instance is "put to sleep" and kept
>> around in case another request is for the same servlet. If the
>> application is taking requests for many different servlets, the
>> servlet instances do slip in and out of the pool as different
>> requests come in, but there is no guarantee that a servlet instance
>> will be brand new with every request.

[Shane Hathaway]
> It sounds like a servlet can re-awaken in a different thread from the
> one in which it was put to sleep.  If that happens, changes made
> before sleeping get registered with a different transaction than the
> transaction being committed.  The new transaction is unaware of the
> change.  Later, you might accidentally commit or abort the original
> transaction.  What a mess!

It's a decent theory, except for the lack of an obvious reason for why they
see these failures on Windows but not Linux (it's possible that, because
Windows is more willing to switch threads frequently, it's more *likely* for
a servlet to re-awake in a different thread on Windows -- provided that's
possible at all, which I don't think we know yet).

> If the above guess is correct, you would benefit from the experimental
> support for binding transactions to connections (like Kapil
> mentioned.) Your servlets span threads; therefore, transactions
> should be bound to connections rather than threads.
>
> The API is still experimental because connection-bound transactions
> really ought to be set up at the time you open the database, not when
> you open the connection.  The API is simple enough that we haven't
> had a strong reason to fix it, though.

Another random <wink> thing to try:  when a servlet re-awakes, call

    get_transaction().begin()