On Fri, 2009-07-24 at 14:27 +0200, Vivien Malerba wrote:
>
>
>
> 2009/7/24 Bas Driessen <[email protected]>
>
>
> On Fri, 2009-07-24 at 14:12 +0200, Vivien Malerba wrote:
>
> >
> >
> > 2009/7/24 Bas Driessen <[email protected]>
> >
> >
> >
> >
> > On Fri, 2009-07-24 at 13:51 +0200, Vivien Malerba
> > wrote:
> >
> > >
> > >
> > > 2009/7/24 Bas Driessen <[email protected]>
> > >
> > > 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.
>
The GDA_CONNECTION_OPTIONS_THREAD_SAFE works OK so far in libgda master.
Question. How can I pass on 2 options with GdaConnectionOptions?
If I use the threads I can use:
connection = gda_connection_open_from_dsn("stocksql", NULL,
GDA_CONNECTION_OPTIONS_THREAD_SAFE, NULL);
How about if I want to use both the GDA_CONNECTION_OPTIONS_THREAD_SAFE
as the GDA_CONNECTION_OPTIONS_SQL_IDENTIFIERS_CASE_SENSITIVE option. How
would I pass that on in gda_connection_open_from_dsn?
Thanks,
Bas.
_______________________________________________
gnome-db-list mailing list
[email protected]
http://mail.gnome.org/mailman/listinfo/gnome-db-list
