MySQL Forums
Forum List  »  Connector/C++

Re: read access violation in xdevapi 8.0.17
Posted by: Rafal Somla
Date: December 17, 2019 08:42AM

Hi John,

I want to reply to your post <,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).

Options: ReplyQuote

Written By
November 20, 2019 04:57PM
Re: read access violation in xdevapi 8.0.17
December 17, 2019 08:42AM

Sorry, you can't reply to this topic. It has been closed.

Content reproduced on this site is the property of the respective copyright holders. It is not reviewed in advance by Oracle and does not necessarily represent the opinion of Oracle or any other party.