On Thu, 2004-02-19 at 17:24, Matt Feifarek wrote:
> 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)
You can ask for certain whether changes were made and avoid any question
of your own 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...)
You should actually close the connection -- call the close() method.
Just before you close the connection, add some variant of this code
assert not get_transaction()._objects
The _objects attribute stores all the objects registered with the
transaction. If you haven't modified anything, the list will be empty.
If you have modified something, the assertion will fail.
> 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)
How does the servlet get its original reference to the connection? I
assume it calls the open() method on the database at the start of each
request. (Just checking, because I haven't seen any code.)
> 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 begin implicitly but are terminated explicitly. When 1) a
thread calls get_transaction() or whenever a persistent object is
modified and 2) a transaction does not already exist, a new transaction
is created. Note that the mechanism in the modification case is for the
connection to call get_transaction(). If a transaction already exists
when you call get_transaction(), it is used.
The transaction is normally associated with a thread. If a thread
begins a transaction but does not finish it, then subsequent calls to
get_transaction() will return the old, in-progress transaction.
Jeremy
-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
_______________________________________________
Webware-discuss mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/webware-discuss
