[egenix-users] Exception exceptions.AttributeError - Depending upon the naming of the module ( connector.py / error_connector.py)

M.-A. Lemburg mal at egenix.com
Wed Feb 11 14:24:33 CET 2009


On 2009-02-11 13:14, Senthil Kumaran wrote:
> On Tue, Feb 10, 2009 at 3:38 AM, M.-A. Lemburg <mal at egenix.com> wrote:
>> At interpreter exit time, Python will clear all modules, but the
>> order in which this happens is undefined (in CPython it depends on
>> the order of the items in the module dictionary at the time of exit,
>> but that's an implementation detail of CPython).
> 
> Thanks for the explanation, Marc. That helped.
> 
>> It is better to keep globals such as the session object in
>> a context object that you pass around in your application
>> code as parameter to the various methods/functions.
> 
> If I understand it properly, you recommend:
> 
> class A:
> 
>        def __init__():
>              ...
>              self.connection = DriverConnect()
>              ...
> 
> objA = A()
> 
> And call
> 
> stormedDB =  StormifyDatabase(objA)
> 
> 
> If I have mis-understood. can you please point me to any example
> snippets which I can look at and design accordingly.

Well, it's a little more complicated than that and requires
a change in the application design:

It is better to store all non-constant global variables in a
context object. Depending on the type of application, this can
be dynamically created in a request handler or the apps startup
code.

You then add all global objects needed for processing the request
to this context object and pass it around as parameter when calling
functions or methods, e.g.

def main():

    # Startup
    context = MyContext()
    context.connection = DriverConnect()

    # Processing
    do_something(context)

    # Finalization
    context.connection.close()

>> Note that it's also better to explicitly close the session
>> object once you're done with the server communication.
> 
> I would like to do that, the but the point is:
> 
> user_script.py - has db_api = <ClientSideObject...>
> Now, I pass this object to storm ORM and the entire application uses
> the stormified object. Returns the value.

This db_api object is the module object you get from the
session object, right ?

Here's a typical example of how you'd use mxODBC Connect:

from mx.ODBCConnect.Client import ServerSession

def main():

    # Setup a server session
    session = ServerSession(config_file='client-config.ini')

    # Connect to the mxODBC Connect Server
    db_api = session.open()

    # Connect to a database
    connection = db_api.DriverConnect('DSN=...;UID=...;PWD=...')

    # Process data on the connection
    ...

    # Finalize the connection
    connection.close()

    # Finalize the server session
    session.close()

Note that there are no module global being used. This assures that
you have controlled garbage collection.

> I have tried doing .close() on __del__() method of the class where I
> am opening the ClientSideObject, but still after  a "couple of
> successful executions" (without any error message in the Server.log)
> I end up at:
>  File "mx/ODBCConnect/Common/ProxyObjects.py", line 675, in __call__
>   File "mx/ODBCConnect/Client/ServerSession.py", line 614, in methodcall
>   File "mx/ODBCConnect/Client/ServerSession.py", line 423, in _response
>   File "mx/ODBCConnect/Common/ProxyObjects.py", line 1191, in process_response
> InterfaceError: Connection limit exceeded. Your license allows 20
> physical database connections.
> 
> called from the very same __del__() method.

Are you running the requests in a for-loop or starting the script
20 or more times ?

> I might share the code at support at egenix.com for further suggestions.

Ok, please send some example code to support. We can then see whether we
need to add special support for your use case to mxODBC Connect
or whether there's another way to achieve what you want.

In any case, we'll make the session object .close() method more robust,
so that it doesn't cause random exception when called during the Python
shutdown process.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Feb 11 2009)
>>> Python/Zope Consulting and Support ...        http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________

::: Try our new mxODBC.Connect Python Database Interface for free ! ::::


   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
           Registered at Amtsgericht Duesseldorf: HRB 46611
               http://www.egenix.com/company/contact/



More information about the egenix-users mailing list