Re: 'MySQL server has gone away' with pool_recycle=1 , what's wrong here?
It looks like for now I'm avoiding the error, but I'm not sure I've solved anything - more like - I've delayed the problem until deployment. If the DB connection pool has low usage and ends up with a number of transactions that are not active for a while - they will expire and this error will be thrown. I'm guessing that for further detail I'll have to look into the SQLalchemy connection pooling details and the questions should be directed to their list. Still - if anyone has experienced this and has further comments - you're welcome. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: 'MySQL server has gone away' with pool_recycle=1 , what's wrong here?
On 11/2/07, Atilla [EMAIL PROTECTED] wrote: If the DB connection pool has low usage and ends up with a number of transactions that are not active for a while - they will expire and this error will be thrown. That's why you set connection_timeout to a significantly lower value than the server has. I use 1 hour on the client and 24 hours on the server. Even 1/2 hour on the client should cause no noticeable overhead. Your original problem was your engine options weren't being passed to SQLAlchemy, thus the timeout. So theoretically you've solved it. -- Mike Orr [EMAIL PROTECTED] --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Status codes for user errors
Mike Orr wrote: Sometimes my controllers discover a user error: a URL pointing to a nonexistent database record, or query/form input that doesn't match what the form HTML would have allowed. The Pylons error system isn't quite what I want; I'd rather send back a regular page with the site decorations and a message saying That record doesn't exist, try searching or You don't seem like a real human. -- with a 400-series status. Because just aborting with 500 makes it look like the site is buggy, and a text error message doesn't have the links to get them back on track. I could adjust the error template style but it seems like overkill when I can just do it in the controller. Is there any problem with just changing the status in the controller and returning an alternate template page? There shouldn't be, just do: response.status_code = 500 Inside the controller method so the correct headers are set (I haven't found a way to alter the message though, you might have to drop to bare WSGI to do that) and then render the template you see fit. Alberto --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: sqlalchemy.exceptions.SQLError: (OperationalError) database is locked
Back to this forum :) For those that care this is similar to a post I made on the earlier referenced post in the SQLAlchemy forum. Changing the isolation_level to immediate stopped the deadlock from occurring. However, another problem comes up very soon. When testing my cart I was noticing that its possible to get multiple items of the same item in the cart if I really hammer at the add cart button (instead of a single item with a quantity 1). Each of these are an AJAX call and therefore I think can processed prior to the previous call returning. What happens is: - I load the shopping cart (and other stuff) - I start a transaction - I check to see if the item is already in the cart. If its there I increment the quantity, if not I add a new item to the cart. - I commit the transaction What can I suspect is the addCart can be called concurrently -- the transaction protects the database lock, but not the now cached data in the in-memory model. This also likely caused the removeCart issue that occurs above since it probably results in removing the same cart item twice causing an error when one of them is flushed to the database. So what is the correct solution here? I don't think that mutex protection of the cart model itself will work as each copy of the cart is presumably a new copy of the underlying data. I could, of course, protect the actual addCart and removeCart method in the web server (as opposed to the model). However, that sucks since it precludes multi- threaded access to separate carts which should be possible. Michael Bayer replied in the SQLAlchemy forum: this would seem to me like it should be fixed at the ajax level, or possibly the level of the webserver where it receives ajax events. your ajax functionality constitutes a GUI, and most GUIs I've worked with have a single event queue whereby all events are serialized into a single stream. the nature of the XMLHttpRequest is asynchronous so it seems like either your ajax library would have to delay the second ajax request until the first one completes, or the web server would have to enforce similar behavior (probably easier on the ajax side). I understand where he is coming from, however, I have to say I'm not very convinced :) It seems to me that in theory at least http requests can arrive from the same host concurrently and there is little that can be done to prevent that ... Any thoughts from you guys? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
for internet addvertisement contact us on [EMAIL PROTECTED] or call us 00923007530720
[EMAIL PROTECTED] 000923007530720 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
