Re: Connection Timeout on remote DB connection

[John Cuyle]

Sort of. I'm not accessing the session from multiple threads at the same time, all session access is sequential. It looks like the problem is that it isn't just session access. The results of the first query are being destroyed on a different thread parallel to issuing the second query, and the results retain a session reference. This is actually somewhat confusing and surprising behavior.

Session appears to use something like a pimpl pattern, where an inner session object is referenced by the session, any results, and any query statements. I really didn't expect that because the Session returned from the pool appears to need to outlive any queries made using the session and any results returned from those queries because that session object force closes the session. I would have expected one of the following two behaviors:

1) The session object follows pimpl pattern, queries and results reference the inner session object, the session gets closed whenever the last reference is released. That would allow you to issue a query without keeping your own reference to the session or worrying about when it gets closed since the last thing that needed it would release the last reference and it would get closed/destroyed automatically as soon as nothing needed it anymore.

2) The Session object has complete control of the lifetime of the session, when it is destroyed the session is closed, and because of that other objects (results, queries) are not allowed to take a dependent reference on the session inner, which prevents a race on the session between destruction of a previous set of results and executing a new query.

What you have now is the worst of both worlds, the caller has control over the session lifetime but the internal implementation of the library is allowed to take dependencies on that lifetime without sharing ownership. The rules are not documented. It was an unpleasant surprise that results still needed the session for something but statement execution didn't hold the session open long enough to complete. It would be preferable to pick one design: Shared ownership of the session with automatic session lifetime (last reference released closes) Or session has sole ownership and other objects are not allowed to expect session lifetime to extend past their own lifetime, or hold references to the session longer than absolutely necessary for lazy cleanup on deletion.