(Lack of) threadsafety
Posted: Fri 08 Dec 2006 15:23
The Ora unit introduces a global variable (in the interface section) called UseDefSession. When the value of this variable is True (which is the default value), the following code turns out to be not thread safe:
OraSession := TOraSession.Create(nil);
// Set OraSession connection properties here
OraQuery := TOraQuery.Create(nil);
OraQuery.Session := OraSession; // This line is not threadsafe
The last line can cause problems in multithreading environments, because setting the Session property of a TOraDataSet descendant, causes the TOraDataset to be removed from a list of “clients” from the current connection that TOraDataSet uses (UsedConnection.UnregisterClient(Self)). This UnregisterClient method eventually calls TCustomConnection.UnRegisterClient from the VCL DB unit, where the list of “clients” is a simple TList, so not thread safe.
When UseDefSession is True, then each TOraDataSet descendant gets the global DefSession assigned immediately when created. Then when explicitly setting TOraDataSet.Session, the TOraDataSet is removed from the list of clients from the global DefSession. This can result in “Access Violation” exceptions of in “List index out of bounds” exceptions.
The simple solution to this problem is to set UseDefSession to False in multithreaded environments. To my humble opinion, it is a bit strange, that the default value of the TOraSession.ThreadSafety property is True (to use the OCI in multi-threaded environments as the help describes) while the default value of UseDefSession undermines thread safety.
Besides that, the locking functions of the global Sessions variable (is a TSessionList which is a TThreadList descendant) are not called (correctly), so thread safety cannot be guaranteed here. Also the creation of the Session list cannot be considered to be thread safe (Creation of multiple TSessionLists is possible), meaning that creation/destruction of TOraSession should be synchronized from the calling source by using Critical Sections.
It seems to me, that a few simple modifications to the Ora unit, could fix a lot of multithreading problems.
Regards,
Erik van Eekeres
DDinformatica
The Netherlands
ODAC 5.70.0.28 for Delphi 7
OraSession := TOraSession.Create(nil);
// Set OraSession connection properties here
OraQuery := TOraQuery.Create(nil);
OraQuery.Session := OraSession; // This line is not threadsafe
The last line can cause problems in multithreading environments, because setting the Session property of a TOraDataSet descendant, causes the TOraDataset to be removed from a list of “clients” from the current connection that TOraDataSet uses (UsedConnection.UnregisterClient(Self)). This UnregisterClient method eventually calls TCustomConnection.UnRegisterClient from the VCL DB unit, where the list of “clients” is a simple TList, so not thread safe.
When UseDefSession is True, then each TOraDataSet descendant gets the global DefSession assigned immediately when created. Then when explicitly setting TOraDataSet.Session, the TOraDataSet is removed from the list of clients from the global DefSession. This can result in “Access Violation” exceptions of in “List index out of bounds” exceptions.
The simple solution to this problem is to set UseDefSession to False in multithreaded environments. To my humble opinion, it is a bit strange, that the default value of the TOraSession.ThreadSafety property is True (to use the OCI in multi-threaded environments as the help describes) while the default value of UseDefSession undermines thread safety.
Besides that, the locking functions of the global Sessions variable (is a TSessionList which is a TThreadList descendant) are not called (correctly), so thread safety cannot be guaranteed here. Also the creation of the Session list cannot be considered to be thread safe (Creation of multiple TSessionLists is possible), meaning that creation/destruction of TOraSession should be synchronized from the calling source by using Critical Sections.
It seems to me, that a few simple modifications to the Ora unit, could fix a lot of multithreading problems.
Regards,
Erik van Eekeres
DDinformatica
The Netherlands
ODAC 5.70.0.28 for Delphi 7