Hello, I have a database adapter, Level3 (inheriting from Shared.DC.ZRDB.TM). All documentation I have found claims that such an adapter should be able to open multiple connections to the database, I see always one though. What am I missing? More detail : ---------------------- I have a folder, a database connection object, ZSQL method and a DTML document, that renders the ZSQL method. Zope is running in 12 threads. I call the DTML document from 8 simultaneous clients, the DTML document however renders one at a time (it takes a while to render), apparently serialized by the database access. There is only one (!) physical connection to the database, I would expect at least 8. How do I speed things up? I looked at DCOracle2DA as reference, cannot see a difference. Thanks for any hint, Michal Bukovjan
Michal Bukovjan writes:
I have a database adapter, Level3 (inheriting from Shared.DC.ZRDB.TM). All documentation I have found claims that such an adapter should be able to open multiple connections to the database, I see always one though. You do not tell us, what database you are using.
When, e.g., your Python DB API module is not multi-thread aware, then the Global Interpreter Lock is not released and only a single thread can run at a time. This is, e.g., a problem for ZODBCDA. Dieter
Dieter Maurer wrote:
Michal Bukovjan writes:
I have a database adapter, Level3 (inheriting from Shared.DC.ZRDB.TM). All documentation I have found claims that such an adapter should be able to open multiple connections to the database, I see always one though. You do not tell us, what database you are using.
When, e.g., your Python DB API module is not multi-thread aware, then the Global Interpreter Lock is not released and only a single thread can run at a time.
This is, e.g., a problem for ZODBCDA.
Dieter
I was talking about my own hacked version of Interbase DA, that is gvibDA / gvib Python API module (also changed/hacked by me). I am experimenting with this, resolving some threading issues, and try to get more performance. I found that, for instance, Zope never looks at threadsafety variable defined by the API variable. The API actually releases the Global Interpreter lock during longer lasting operations like fetch or execute (if we are talking about Py_THREADS_ALLOW_BEGIN / END combos), but at any case, there is always only one physical connection (I can tell it by number of active DB server connections), which is being used by multiple Zope threads. A second connection is never started, no matter how I changed the gvibDA / gvib so far. Michal
Michal Bukovjan writes:
... but at any case, there is always only one physical connection (I can tell it by number of active DB server connections), which is being used by multiple Zope threads. Maybe, there is some (module global) connection cache used, that's happy it finds already a connection for the given connection string...
A second connection is never started, no matter how I changed the gvibDA / gvib so far.
Dieter
participants (2)
-
Dieter Maurer -
Michal Bukovjan