Re: Exception exceptions.AttributeError - Depending upon the naming of the module ( connector.py / error_connector.py)
"M.-A. Lemburg" <[email protected]>
| Newsgroups | gmane.comp.python.egenix.user |
|---|---|
| Organization | eGenix.com Software GmbH |
| Message-ID | <[email protected]> |
On 2009-02-11 13:14, Senthil Kumaran wrote: > On Tue, Feb 10, 2009 at 3:38 AM, M.-A. Lemburg <[email protected]> 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 [email protected] 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/ _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ https://www.egenix.com/mailman/listinfo/egenix-users