Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-pascal / 2015-01

DB Access and Multithread

4 messages · 4 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Fabrício Srdic

Hello,

The DB access framework of the fpc is not thread safe.

So, how can i build a multithreaded application that requires access to database?

If each one of my threads use its own set of DB access components, that is, don´t share any instance of db access components, this can be a secure workaround?

Best regards

Reply by email

Michael Van Canneyt
to Fabrício Srdic
Fabrício Srdic wrote 5 lines
Hello, The DB access framework of the fpc is not thread safe. So, how can i build a multithreaded application that requires access to database?

Create 1 connection per thread.
Do not share connections (and datasets connected to it) over threads.

If each one of my threads use its own set of DB access components, that is, don´t share any instance of db access components, this can be a secure workaround?

Yes, if they use a connection per thread.

The main problem is that the 'Database' and 'Transaction' properties of TDBDataset and descendents (TBufDataset and TSQLQuery) are not thread safe: The TDatabase class maintains a list of connected datasets. The management of this list is not thread-safe, it needs to be changed to a TThreadList. This is on my todo list, but is part of a bigger rework.

Note that the underlying DB client library also may not be thread safe.

Michael.

Reply by email

Michael Schnell
to Fabrício Srdic: The DB access framework of the fpc is not thread safe. So, how can i build a…
Fabrício Srdic wrote
Hello, The DB access framework of the fpc is not thread safe.

IMHO you should never use the therm thread save in such a generalization. You need do be a lot more specific.

I never took a look at "The DB access framework of the fpc", so I can't comment on this but e.g. TList obviously is not thread save (that is why we have TThreadList), but anyway it's no problem to instantiate a TList object and use that exclusively from a single Thread, and then instantiate another TList object and use that exclusively from a different single Thread. Hence you could say "TList is thread save but it's instantiations are not". Maybe it's similar with "the DB framework".

AFAIK, Indy is thread save (of course provided the user adheres to a lot of necessary precautions that might not be explicitly documented).

I do know that a friend of mine used Delphi and Indy with a heavily multithreaded project.

-Michael

Reply by email

JB
to Michael Schnell

I work with connection pool, a threaded control to provide avail connections.

Best regards,

JB

José Benedito
JBS Soluções
Consulting Systems Development
c
www.jbsolucoes.net

skype:
+55 22 30251654
+55 22 996064279

Michael Schnell wrote 29 lines
On 01/30/2015 10:56 PM, Fabrício Srdic wrote: > Hello, > > The DB access framework of the fpc is not thread safe. > IMHO you should never use the therm thread save in such a generalization. You need do be a lot more specific. I never took a look at "The DB access framework of the fpc", so I can't comment on this but e.g. TList obviously is not thread save (that is why we have TThreadList), but anyway it's no problem to instantiate a TList object and use that exclusively from a single Thread, and then instantiate another TList object and use that exclusively from a different single Thread. Hence you could say "TList is thread save but it's instantiations are not". Maybe it's similar with "the DB framework". AFAIK, Indy is thread save (of course provided the user adheres to a lot of necessary precautions that might not be explicitly documented). I do know that a friend of mine used Delphi and Indy with a heavily multithreaded project. -Michael _______________________________________________ fpc-pascal maillist - http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Reply by email