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

[Shane Hathaway]

On Thu, 19 Feb 2004, Matt Feifarek wrote:

> 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()

As a sanity check, you might consider calling get_transaction().commit()
every time.  If there have been no changes, it does no harm.  
Alternatively, you can call get_transaction().abort() if no changes were
intended.  A third alternative is to assert that
get_transaction()._objects is empty when you made no changes (although
that's not a public API.)

> 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)

Since transactions are bound to threads, the transaction stays, along with 
anything registered in the transaction.

If an exception occurs at any point in this process, do you abort the 
transaction in a "finally" clause?  If you don't, the transaction has no 
way to know that it should be aborted.

> 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?

Transactions containing no objects are harmless, that's correct.  It might
help to watch calls to Transaction.register().  I learned a lot by adding
print statements there.

Shane