[Zope] Interbase gvibDA Adapter - Threading and Interbase Roles

[ender]

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