Hi John,
I want to reply to your post <
https://forums.mysql.com/read.php?167,680721,682527#msg-682527>; which is in a different thread but I think it really belongs here. First of all, thank you for an interesting comment.
The big picture we wanted is that things work as transparently for the user as possible. So there is RAII principle in place - after you create and use a session, things should be cleared up when the session is destroyed or goes out of scope (session is closed, or returned to the pool, resources deallocated etc.). But this is not so simple when you write code like this:
TableSelect select(...) {
Session s(...);
return s.getSchema().getTable().select()...;
}
The table select statement you return still refers to the session even if session object s is gone. This should still work, internally using techniques like shared pointers to implementation object. So we expect that session is closed only when the last object that uses it gets destroyed.
This does require extra care, esp. in multi-thread application, because X DevAPI is written under assumption that each X DevAPI object can be used only by a single thread at a time and the responsibility to ensure this lies on the user.
And even without multiple-threads, there is also this limitation that next query can be issued in a session only when processing of the previous query has finished. If code separates session management from handling of queries and results, then it needs some mechanisms to ensure above restriction (it can be simpler to not separate it but use a client object and create temporary sessions whenever needed).
I think there are very many ways the user code might want to use our library and solution which works for one pattern will not work for others. For example, I don't think your suggestion that destroying a session object invalidates all related objects, such as queries and results is necessarily a good one. It will make code like above not work as expected.
We try to make some good balance here. From the analysis of your issue, I still believe that the root cause was a concurrent access to the same object from 2 different threads, and not some logical error in our API implementation. But we are open for further comments and suggestions.
If you do continue experimenting with this, it would be good to upgrade to 8.0.18 or later, because around that version we changed internal implementation of the code that is related to your issue (for example, the mysqlx::Result class is no longer there and is replaced by something else).