On Thu, Sep 4, 2014 at 5:53 PM, Michael Bayer mike...@zzzcomputing.com
wrote:
The code I say appears to expect the session_id to remain on detached
states in certain situations is that the check in Session._attach checks
not only the session_id but that the referenced session still exists in
On Sep 5, 2014, at 12:03 PM, Lonnie Hutchinson lonn...@skytap.com wrote:
On Thu, Sep 4, 2014 at 5:53 PM, Michael Bayermike...@zzzcomputing.com wrote:
The code I say appears to expect the session_id to remain on detached
states in certain situations is that the check in
Here is the basic outline of the web request hander. It creates an
operation, gets the return value, and either spawns a thread to execute the
operation (with non-sqlalchemy related instrumentation) or completes the
execution on the operation model. In the case I see there is a provisioning
phase
On Sep 4, 2014, at 5:00 PM, Lonnie Hutchinson lonn...@skytap.com wrote:
I am using sqlalchemy 0.8.5 with mysql 5.5 and think an intermittent failure
I am seeing may be due to an issue in sqlalchemy. Very infrequently I receive
an error from Session.add() stating the instance is already
The session executes in one of many web-server threads, but there is no
multi-threading with respect to the session or the objects. The session
that was closed is within an initializer and upon return a method on the
object is executed that creates a new session and tries to attach objects
On Sep 4, 2014, at 8:17 PM, Lonnie Hutchinson lonn...@skytap.com wrote:
The session executes in one of many web-server threads, but there is no
multi-threading with respect to the session or the objects. The session that
was closed is within an initializer and upon return a method on the
