Version 3.4.2 - still having problems with hang when terminating application!

[Helene]

We are using Delphi 5, and recently installed version 3.4.1. Problems with the application hanging when terminating, and also in some other circumstances, started to appear. I then downloaded 3.4.2 and installed that version. It still is hanging.

The debugger shows it stops in the OracleMonitor unit, in the execute method. Terminate is false.

We are using Delphi runtime packages, and the monitor was included in one of these packages. It is not included in the project's main form.

Helene

 

[Che Ming]

Me too. I have met trouble with OracleMonitor unit long long ago, but DOA has no any progress on solving this problem.

 

[Helene]

It is rather urgent for us to get this fixed. We have a release date coming up soon. Not including the OracleMonitor unit in the project does not help. I am not quite sure the problem is really related to the Monitor. Debugging this problem is really hard.

I have tried to include the call to InternalMonitorFinalize in my own code, right after the database session is logged off. Right before this call the Thread status shows there are three threads in my application. After the call one thread disappears, which is OK. However, I am a bit confused as to why there are three threads - what is the third one? As far as I know, we should have only one thread in the application. After watching that thread 3 disappeared, I pressed Run, and then suddenly there were three threads again. And the application was hanging again. I noticed the Monitor finalization procedure is not a class method. Since it will point to nil after it has been called once, it will indeed be a problem if for any reason several monitor threads have been created.

I don't know if this is of any help to you, but the main message is I am starting to feel a bit desperat and I am running out of time...

I also found that it is a tedious job to go back to the previous DOA version to try wheter that makes the problem go away. Even if you have not made use of any new funcionality the default value of all new properties is automatically stored in the dfm file once you open it and save it to file. I strongly suggest for the future that you make use of the default keyword for all published properties.

property X: Boolean read fX write fX default false;

and then include X:=false; in the constructor of the component.

Pro's: This makes the DFM files smaller, makes it easier to see which properties actually have been given a value different from the default, and also makes it a lot easier to revert to a previous version of a component if necessary. Con's: none ??

PLEASE do this for the next main version you release!

 

[Helene]

YES, the problem is solved!

It turns out it was a code optimization intent (!) which caused the problem to occur. I still can't see why it should have this impact, but I will explain to you what happened.

We have a component of our own which inherits from TOracleDataset. This component made use of another TOracleDataset instance in one internal procedure. The procedure looked somehwat like this:

proc x;
var ds: TOracleDataset;
begin
ds:= TOracleDataset.Create (Owner);
try

Finally
ds.Free;
end;
end;

This worked ok. What I did, which caused the entire problem (which seems to occur also with DOA version 3.3.2, by the way), was to move the ds to the private section of my dataset class; and set up the code like this:

TmyDataset = class(TOracleDataset);
private
dm:TOracleDataset;

constructor TmyDataset.Create(Owner );
begin
inherited Create (owner);
dm:=nil;
End;

Tmydataset.myDSFunction;
begin
dm:=TOracleDataset.Create (Owner);

dm.CloseAll;
end;

desctructor TMyDataset.Destroy;
begin
if assigned (dm) then dm.Free;
inherited Destroy;
end;

Maybe it can work if using Self instead of owner as the owner of the dm instance. For the time being I just reverted to the prior code, which works!!

Another thing you may want to know, is that this does not only hang when terminating the application, actually it will hang when a datamodule containing a TMyDataset instance is freed.

 

[Marco Kalter]

If the TMyDataSet instance owner also owns the TOracleDataSet instance (dm), then it will already implicitly free it. I'm not sure if this could cause the error though. Perhaps you should simply not free it, and leave the to the owner.

I have added your request about the property default values to the enhancement requests. This is indeed useful when switching back to older versions.

------------------
Marco Kalter
Allround Automations

 

[Marco Kalter]

Originally posted by Che Ming:
Me too. I have met trouble with OracleMonitor unit long long ago, but DOA has no any progress on solving this problem.

If this is still the case with version 3.4.2, let me know.

------------------
Marco Kalter
Allround Automations

 

[JSchlosser]

I'm using C++Builder 5.0 with patch#1 and DOA 3.4.2.
When linking a DLL file with #pragma link "OracleMonitor", the Application hangs while terminating, as described by Helen. If I comment this line, everything works fine.

The EXE-File, which calls the DLL, does not use OracleMonitor.

 

[Marco Kalter]

This is indeed still an issue when a DLL is implicitly loaded and unloaded by using the external reference. When it is unloaded, the monitor finalization code runs, but the monitor thread in the DLL has somehow stopped. You can fix this by explicitly finalizing the monitor when the application stops. Within the DLL, you need to execute the following line:

Delphi:
if Assigned(InternalMonitorFinalize) then InternalMonitorFinalize;

C++Builder:
if (InternalMonitorFinalize != NULL) InternalMonitorFinalize();

This code will work, regardless if you have included the monitor unit or not. If you have some finalization code in the actual DLL that you call from the host application, you can simply add this call there.

We will have a fix for this in the next patch release.

------------------
Marco Kalter
Allround Automations

 

[VanRoie]

Hi,

I try your fix but it did not work.
Here is the code I use

uses ...
OracleMonitor, ...

...

initialization

finalization
if Assigned(InternalMonitorFinalize) then InternalMonitorFinalize;

the code still hang up in the InternalMonitorFinalize;

The program is a Three tiers application, more precisely an InprocServer (.DLL)

I simply open and close the application without any connection to the DB

I use Delphi5 Enterperise + DOA 3.4.3

Thanks for your help
Dominique