I found a workaround...
Setting WSGIApplicationGroup = ${GLOBAL}
for each app and adding a patch to sqlalchemy.databases.firebird.py to
check self.dbapi.initialization before calling self.dbapi.init()
This causes all the apps to run under one python subinterpreter and
the global variable in kinterbasdb will accurately reflect whether or
not it has been set.
This:
http://code.google.com/p/modwsgi/wiki/ApplicationIssues
had a lot of helpful information.
On Sep 30, 4:39 pm, Michael Shaw <[EMAIL PROTECTED]> wrote:
> Sorry for not explaining myself more clearly, but the global
> initialized variable in the kinterbasdb module being set to true
> (which it should be once initialized) is check first thing when the
> init method is called.
> This is supposed to throw a specific programming error.
> relevant code from kinterbasdb.__init__.py
> ...
> initialized = False
> def init(type_conv=1, concurrency_level=_k.DEFAULT_CONCURRENCY_LEVEL):
> global initialized, _MINIMAL_TYPE_TRANS_TYPES, \
> _NORMAL_TYPE_TRANS_IN, _NORMAL_TYPE_TRANS_OUT
>
> if initialized:
> raise ProgrammingError('Cannot initialize module more than
> once.')
>
> if _k.DEFAULT_CONCURRENCY_LEVEL == 0:
> if concurrency_level != 0:
> raise ProgrammingError('Support for concurrency was
> disabled at'
> ' compile time, so only Level 0 is available.'
> )
> # Since only Level 0 is available and it's already active,
> there's no
> # need to do anything.
> else:
> if concurrency_level not in (1,2):
> raise ProgrammingError('Only Levels 1 and 2 are accessible
> at'
> ' runtime; Level 0 can only be activated at compile
> time.'
> )
> ##### this is where the actual exception gets raised... ########
> _k.concurrency_level_set(concurrency_level)
>
> On Sep 30, 4:26 pm, Michael Bayer <[EMAIL PROTECTED]> wrote:
>
> > On Sep 30, 2008, at 2:46 PM, Michael Shaw wrote:
>
> > > I am working on two projects that are bothing running under mod_wsgi.
> > > The first is using kinterbasdb directly (no sqlalchemy).
> > > The second is using sqlalchemy.
> > > Problem arises when one or the other attempts to call kinterbasdb.init
> > > after the other one has already done so.
> > > My question is this:
> > > When sqlalchemy attempts to initialize kinterbasdb, it appears to be
> > > calling it with:
> > > def create_connect_args(self, url):
> > > ...
> > > global _initialized_kb
> > > if not _initialized_kb and self.dbapi is not None:
> > > _initialized_kb = True
> > > self.dbapi.init(type_conv=type_conv,
> > > concurrency_level=concurrency_level)
> > > If kinterbasdb has already been intialized this is supposed to
> > > immediately throw a ProgrammingError.
> > > But the programming error is getting thrown when it attempts
> > > _k.concurrency_level_set(concurrency_level)
>
> > > Could importing kinterbasdb inside databases.firebird.py and referring
> > > to it as dbapi during the call to init be causing this? Anyone with
> > > more experience able to express this better?
>
> > its not that the module is called "dbapi", its just that the
> > firebird.py dialect is assuming that its own _initialized_kb variable
> > holds the state of whether or not init() has been called. A better
> > approach would be if the firebird DBAPI could be queried for whether
> > or not it's legal to call init(). If catching the ProgrammingError
> > is the only option, that might be needed within the firebird dialect.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"sqlalchemy" group.
To post to this group, send email to sqlalchemy@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en
-~----------~----~----~----~------~----~------~--~---
