Interbase gvibDA Adapter - Threading and Interbase Roles
Hi, I was wondering whether you could tell me which way we should go when using the gvibDA database adapter. In your documentation it says: "gvib.threadsafety This attribute indicates what level of thread safety the code supports. It is set to 1 - Threads may share the module but not connections." In Zope does this mean that database requests are serialized or will the connection crash if two or more SQL methods attempt to use the connector simultaneously? Your documentation appears to suggest that using External Methods which open and close the database in a single pass enables us to bypass the thread safety problem, by riding on the back of the ZODB multi-threaded architecture. Is that true or would a heavy traffic site that is constantly opening and closing connections bring Interbase to it's knees? Finally, it doesn't appear that either gvibDA or ZODBC support Interbase roles. I guess we don't really need them anyway if we use Zope's security properly :-) ---------------------------------------------------------------------------- --------------------------------- W.Robert Kellock Ph: +64 3 326 6115 Sales Manager Fax: +64 3 326 6115 Credit Systems Control Ltd Web: www.creditscore.co.nz "making decisions easy" ---------------------------------------------------------------------------- ---------------------------------
On Tuesday 06 February 2001 01:20, W. Robert Kellock wrote:
Hi,
I was wondering whether you could tell me which way we should go when using the gvibDA database adapter. In your documentation it says:
"gvib.threadsafety
This attribute indicates what level of thread safety the code supports. It is set to 1 - Threads may share the module but not connections."
In Zope does this mean that database requests are serialized or will the connection crash if two or more SQL methods attempt to use the connector simultaneously?
access will not be serialized, such db adaptors due exist but are obiviously not useful for high scale production (ZPygre comes to mind). each thread maintains a copy of the connection object and therefore a connection. hence you can have two sql methods executing in separate threads, since each will have its own connection, keep in mind there are two kinds of thread safety, zope DA threadsafety and DB-SIG threadsafety? Chris Petrilli has some useful docs on his zope page that will clear this up. i'm bit a sketchy here since i don't understand where higher levels of zope threadsafety DAs come into play?
Your documentation appears to suggest that using External Methods which open and close the database in a single pass enables us to bypass the thread safety problem, by riding on the back of the ZODB multi-threaded architecture.
IMO, a very bad idea if its even doable. a zodb base DA connection is required to make the magic of ZSQL methods work. plus there are added concerns of integrating properly with the transaction machinery, etc. i'm not sure how you think this allows you to get ZODB benefits, since external methods are external to the zodb and zope.
Is that true or would a heavy traffic site that is constantly opening and closing connections bring Interbase to it's knees?
probably (depends on interbase connection arch), ZODB based DA connections are persistent on a per thread basis (ie connection*num_threads on heavy hit site), so you won't get the cost assoc with opening and closing connections. kapil
participants (2)
-
ender -
W. Robert Kellock