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

[Matt Feifarek]

Shane Hathaway wrote:

>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!
>  
>
I'm not sure I understand, no changes are EVER made before sleeping 
without a commit. But here's a better re-cap of what I DO understand:

1. A servlet either exists, or is instantiated
2. As a part of it's building of state, it gets a database connection, 
and then a handle on an object in the db
3. If no changes are made to the object, no get_transaction().commit() 
is run
       (we know if changes are made, with good certainty)
4. If changes ARE made, we do call get_transaction().commit()
5. Before the servlet "shuts down" we assign the references to the 
object, to the root, to the connection all to None (but we do NOT 
delattr() them...)
6. The servlet is removed back to the pool, waiting to be deployed into 
a different thread
       (there should be no object references or root or connection 
references at this point)

I don't understand how there could be any transaction confusion. How 
could one "transaction" stay around from one servlet lifecycle to the 
next? Why would it stay in the thread if it was never used or after it 
was commited? I have seen that connection instances are re-used when you 
get a "new" one... but only one of two things can happen: no changes 
have been made (therefore no "transaction", right?) OR changes are made 
and IMMEDIATELY after, we commit() the transaction.

Somewhere in there lies my misunderstanding: do "transactions" stay 
around, even after they are committed? And are there "transactions" that 
exist even if no data has been changed? If there are, so what? Why does 
code have to treat them so lightly if it didn't actually do anything?

>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.
>  
>
This seems reasonable. But I'd still like to try and understand the 
nature of transactions.

Thanks again. This whole thread has been extremely helpful!