I suspect that the current way we're using SQLAlchemy or databases could be involved in the issues we're newly having with scripts slowing down and ultimately crashing ArcGIS.
From this old thread (http://code.env.duke.edu/projects/mget/ticket/284) I'm wondering if we're experiencing a threading issue (the issues only occur when run as script tools, in process, not any other time for slowdowns). It seems like either some remnant of PISCES scripts remains, or a conflict occurs.
Original comment by Nicholas Santos (Bitbucket: nickrsan, GitHub: nickrsan).
Changed title and plan to leave this open. The issue of performance seemed to be unrelated (but was connected to the logging mechanism). We should still change how we use sqlalchemy to be in line with best practices
nickrsan
commented
9 years ago
Original report by Nicholas Santos (Bitbucket: nickrsan, GitHub: nickrsan).
I suspect that the current way we're using SQLAlchemy or databases could be involved in the issues we're newly having with scripts slowing down and ultimately crashing ArcGIS.
From this old thread (http://code.env.duke.edu/projects/mget/ticket/284) I'm wondering if we're experiencing a threading issue (the issues only occur when run as script tools, in process, not any other time for slowdowns). It seems like either some remnant of PISCES scripts remains, or a conflict occurs.
If it is SQLAlchemy, it's likely because we're using it incorrectly. See http://docs.sqlalchemy.org/en/rel_0_9/orm/contextual.html#using-thread-local-scope-with-web-applications as a starting point for making it work correctly with threads, and this page (http://docs.sqlalchemy.org/en/rel_0_9/orm/session_basics.html#session-faq-whentocreate) for how we should be managing connections and sessions.
Currently calling this minor, but without attention, it could get more serious.