[Zope] ZODB Conflict, Thunked_TM and transaction hoseups MORE INFO

[Brad Clements]

On 13 Jul 2002 at 8:03, kapil thangavelu wrote:

> but the problems your seeing are exactly almost exactly the symptons of some 
> txn and transaction bugs that have been fixed in 2.5.1. i did a write up of 
> the details at.
> http://www.zope.org/Members/k_vertigo/ShortStories/Transactions/TxnProblems.txt

I've looked at your patch, and compared it to the 2.5.1 source. Note that I'm using 
Thunked_TM, which doesn't appear to work exactly like TM. I've changed my 
Thunked_TM to use _finalize and also changed the order of thunk_lock.release to be 
after all changes to _registered (except for the initial register)

However problem still remains. Basically what is happening is multiple db's are being 
created. I think this is the crux of the problem. I'm getting multiple connections to the 
database when there should be only exactly one.

gvibDA's db is: class DB(Shared.DC.ZRDB.THUNK.THUNKED_TM):

However I'm getting multiple instances created. As soon as a 2nd instance appears, 
the application fails in that  the two different connections don't see each other's sql 
transactions. It appears that commit() is no longer being called on one of the 
connections.

So . I need to find out why I get additional db's created, and how it is that I'm getting a 
"dead" one.

I get the DB() object using an external method:

def GetDB(self):
    """Return database"""
    global dbPool
    daobject = getattr(self,gvibObjectName)
    dbobject = daobject()

gvibObjectName is the Zope id of my Interbase connection


> i find it strange that you might have run into them as your running 2.5.1, 
> but its possible if you're trying to directly call the tm interface instead 
> of letting the transaction drive the interaction beyond the intiial 
> _register().

I am only calling _register()

> one question, are you using any sub transactions as well? 

no

> its also likely from the description that, there are other problems 
> (stylesheet conflicts).

I don't know why these appear, but they do not appear to be related to the problem. 
That's a red herring.


Brad Clements,                bkc@murkworks.com   (315)268-1000
http://www.murkworks.com                          (315)268-9812 Fax
AOL-IM: BKClements