Re: [gnome-db] Threads.

[Vivien Malerba <vmalerba gmail com>]

2009/7/24 Bas Driessen <bas driessen xobas com>

On Fri, 2009-07-24 at 14:12 +0200, Vivien Malerba wrote:

2009/7/24 Bas Driessen <bas driessen xobas com>

On Fri, 2009-07-24 at 13:51 +0200, Vivien Malerba wrote:

2009/7/24 Bas Driessen <bas driessen xobas com>

Hello,

Question regarding libgda and threads.

I open a data source connection (ie: gda_connection_open_from_dsn) in thread 1 and then I try to perform any action on the connection (ie: gda_connection_statement_execute_select) in thread 2. If I do this in Postgresql all works fine. If I try to do this in MySQL then the system appears to hang in thread 2. I assume because thread 1 is holding a lock on the connection.

How can I remove the lock that is set by function gda_connection_open_from_dsn so I can access the connection information from thread 2?

Perhaps slightly out of libgda scope, but is there a difference between Postgresql and MySQL when it comes to threads and locking? It appears that Postgresql does not have that concept or perhaps by default configured not to use threads?

The same kind of limitation also applies to PostgreSQL which is usually not compiled with thread support in client libraries. The discrepancies between databases' client libraries regarding threads have led me to create the GDA_CONNECTION_OPTIONS_THREAD_SAFE flag (in 4.1, not in 4.0) where a connection can be used by any thread, regardless of the thread which created the connection (in fact a thread is created per connection and the user threads synchronize with that thread when running statements, it relies on the GdaThreadWrapper object).

My previous message crossed this one. So if I understand correctly,  in fact my Postgresql is NOT thread safe and therefore it is working and the MySQL IS thread safe and therefore it is "hanging" on a lock.

It is working in PostgreSQL because PostgreSQL has been compiled with the thread safe flag, and it's not in MySQL because MySQL has not been compiled with that feature (in that case the provider prevents usage from a thread different than the one which created the connection, and sometimes even prevents the usage from a thread which did not create the provider itself, it depends on the client libraries limitations).
 

How/where can I set this GDA_CONNECTION_OPTIONS_THREAD_SAFE flag in 4.1?

It's one of the flags which can be passed as the options argument to gda_connection_open_from...().
 

Is there any workaround/solution in 4.0? Any chance to add this flag in 4.0 or will that break any API rules etc?

It would be a lot of work to add it back as many things have changed in 4.1, and I don't consider it as a bug fix (which is what goes into 4.0 now) but as a new feature. Anyway, you can make a copy of the GdaThreadWrapper object and use it directly in your code for the time being.

Ok, understand. In that case I  should let my "4.0 obsession" go and start working with the 4.1 tree. As explained before, it is convenient to have stuff in 4.0 as the big Linux distros ship that release now.  Will compile everything up with 4.1 using the new GDA_CONNECTION_OPTIONS_THREAD_SAFE flag and go from there. Thanks for your help today.

I understand your concerns here, and I still think it's possible to use the 4.0 and  "do the job yourself"  regarding the threads handling, and the GdaThreadWrapper object can help you in this regard.

Vivien