it only has to do with what your appserver does when a connection is broken.    
 The "finally" method is probably never called.    You can change the Python 
warnings filter to emit those warnings as exceptions, in which you should be 
able to get stack traces in your logs.


On Dec 23, 2010, at 3:02 PM, Hector Blanco wrote:

> Thank you for your quick reply!
> 
> I tried to change the method that grabs the user to:
> def getByName(userName):
>       retval = None
>       try:
>               retval = Database.session.query(User.User).filter(
>                               User.User.userName== userName
>                       ).scalar()
>       finally:
>               Database.session.close()
>       return retval
> 
> but it still doesn't seem to work.
> 
> Maybe it's a problem with threading... I setup the database (create
> the tables, create and insert in the database a sample "test" user...)
> using Google Chrome and I try to log in with Firefox. The database is
> setup in one of the pages the server provides: I write
> http://127.0.0.1/test/initdb as the address of the web page to load in
> Chrome and when the page is rendered, the database is setup. After
> that, I try to log in with the "test" user using Firefox and that's
> when I get the "Error closing cursor: (2014, "Commands out of sync;
> you can't run this command now")" I am using MySql administrator and
> the values for that "test" user seem to be properly created properly.
> 
> Maybe when I create the database with Chrome Firefox doesn't "see" it 
> properly?
> 
> To add a user, I have created a method "update" like this:
> 
> @staticmethod
> def update(user):
>       if isinstance(user, User.User):
>               try:
>                       if user.id:
>                               #User already exists in the database
>                               user=Database.session.merge(user)
>                       else:
>                               #User is new
>                               user=Database.session.add(user)
>                       Database.session.commit()
>               finally:
>                       Database.session.close()
>       else:
>               raise TypeError("Received parameter %s of type %s when expecting
>                                       %s" % (user, type(user), User.User))
> 
> When (from Chrome) I invoke the page that creates the database, a new
> User() instance is created, with a few default values (userName =
> test, for instance) and it's added to the database using this "update"
> method (said user doesn't have an id, so it should be added using
> add(user) ). Then I try to login with the user "test" from Firefox and
> it breaks...
> 
> 2010/12/23 Michael Bayer <mike...@zzzcomputing.com>:
>> 
>> On Dec 23, 2010, at 2:09 PM, Hector Blanco wrote:
>> 
>>> Hello everyone!
>>> 
>>> I am currently working with a webserver (Grok) that starts different
>>> threads (automatically) for the requests that arrive to it.
>>> 
>>> The information is serialized in a MySQL database (which is acceded
>>> through SqlAlchemy). The users' information is stored in that MySQL
>>> database. The plugin that said server uses to check if a user is
>>> logged in or not is called very often. The way it is programmed now
>>> (I'll improve that in the future) is: it goes to the database, tries
>>> to extract the user whose "username" matches with the logged (or the
>>> one trying to log) one and checks if the password stored in the
>>> database matches with the one provided by the user.
>>> 
>>> For some reason, if a user cancels the login process (hits Esc in his
>>> browser) and tries to login again, something (I don't know what)
>>> crashes:
>>> 
>>> 2010-12-23 13:45:50,841 WARNING [sqlalchemy.pool.QueuePool.0x...5450]
>>> Error closing cursor: (2014, "Commands out of sync; you can't run this
>>> command now")
>> 
>> If connection resources are returned to the pool via garbage collection, 
>> this may happen in a distinct, deferred gc thread, producing errors like 
>> this.    It is common for web app servers to throw some kind of interruption 
>> exception when the connection is unexpectedly closed.   The error is caught 
>> and logged as a warning only and should be otherwise harmless.  If you could 
>> apply a "finally:" block around connection interruption errors and cleanly 
>> close the session, that would probably alleviate the warnings.
>> 
>> 
>> --
>> You received this message because you are subscribed to the Google Groups 
>> "sqlalchemy" group.
>> To post to this group, send email to sqlalch...@googlegroups.com.
>> To unsubscribe from this group, send email to 
>> sqlalchemy+unsubscr...@googlegroups.com.
>> For more options, visit this group at 
>> http://groups.google.com/group/sqlalchemy?hl=en.
>> 
>> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "sqlalchemy" group.
> To post to this group, send email to sqlalch...@googlegroups.com.
> To unsubscribe from this group, send email to 
> sqlalchemy+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/sqlalchemy?hl=en.
> 

-- 
You received this message because you are subscribed to the Google Groups 
"sqlalchemy" group.
To post to this group, send email to sqlalch...@googlegroups.com.
To unsubscribe from this group, send email to 
sqlalchemy+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/sqlalchemy?hl=en.

Reply via email to