the MetaData object holds one Table object per unique name given. If you use the Table constructor more than once with the same name and the same MetaData, you get this error.
That's how the error is caused, then the fact that the error is "occasional" points strongly to a race condition of some kind, more than one thread both calling the constructor for Table with the same name. Patterns that could cause this could be some kind of unsynchronized global registry or singleton object that when called produces a new Table object. The recommended pattern is for Table objects (as well as mapped classes) to generally be declared at the module level so that these names are produced only at module import time, which itself should occur before the application starts any threads in addition to the main application thread. On Oct 20, 2013, at 11:04 PM, Joseph Casale <jcas...@gmail.com> wrote: > I have a module that is imported by several Python scripts run by an > application > that fires up a new interpreter session for each invocation. When not under > load or > running the code manually at the cli things work fine but once the concurrency > raises and the application starts seeing some load it emits > InvalidRequestError > exceptions on one table. > > After searching I am not sure the results relate to my issue or maybe my lack > of familiarity with SQLAlchemy has the better of me. > > Any guidance would be greatly appreciated, > jlc > > -- > You received this message because you are subscribed to the Google Groups > "sqlalchemy" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to sqlalchemy+unsubscr...@googlegroups.com. > To post to this group, send email to sqlalchemy@googlegroups.com. > Visit this group at http://groups.google.com/group/sqlalchemy. > For more options, visit https://groups.google.com/groups/opt_out.
signature.asc
Description: Message signed with OpenPGP using GPGMail
