AV when using TOracleSession from different threads

[Frantic]

Hi! I have 2 threads:

• 1 is calling Oracle stored procedure 2-3 times per second
• 2 is main thread

When first is active and second one calls some Oracle procedure, I get Access violation at address 60667232 in module 'OraClient9.Dll'. Read of address 0000000C

Additional information:
I have one instance of TOracleSession, ThreadSafe := True;

Call stack:

Main ($f20):
60667232 +022 OraClient9.Dll                            kpucHTtoIL
606754ad +62d OraClient9.Dll                            kpuexec
60601bd5 +025 OraClient9.Dll                            OCIStmtExecute
046b6d51 +031 oci.dll                                   OCIStmtExecute
00597c2b +6a7 HelpDesk.exe   Oracle           8937 +148 TOracleQuery.InternalExecute
005989ae +0aa HelpDesk.exe   Oracle           9238  +18 TOracleQuery.ExecuteArray
00598899 +075 HelpDesk.exe   Oracle           9192   +9 TOracleQuery.Execute
00592153 +09b HelpDesk.exe   Oracle           6759  +12 TOracleSession.InTransaction

Any ideas/suggestions?

 

[Marco Kalter]

You should check if the 2 threads are not accessing the same TOracleQuery, TOracleDataSet, or TOraclePackage instances.

 

[Frantic]

Marco, thank you for your answer! I checked: every thread has it's own TOracleQuery... But I found an error in TOracleSession:

There is a method called TOracleSession.InTransaction. It uses internal Query: TOracleQuery object to execute simple SQL request. This object is created once for every TOracleSession instance, so when 2 threads are calling SomeOracleSession.InTransaction at the same time AV is raised.

My solution: I added critical section (Enter/Leave) into the InTransaction method.

 

[Marco Kalter]

Thanks, we'll fix it!

 

[giga]

Hi, which version of DOA fix this problem? Is there any workaround for it (I have no DOA source)? I get this error randomly several times a day

For test purpose I create one session per thread now and it works better. Unfortunatelly error still occurs.

Maybe this problem is caused by something else .. any idea?

I found similar post "Oracle AV Problem" but is is without solution

19.10.2010 11:55:18 { Original Exception - Access violation at address 00000000. Read of address 00000000 }
[00404547] System.@HandleAnyException + $33
[00530369] Oracle.TOracleQuery.InternalExecute + $399
[00530CAE] Oracle.TOracleQuery.ExecuteArray + $AA
[00530BB9] Oracle.TOracleQuery.Execute + $61
[0051791B] OracleData.TOracleDataSet.InternalOpen + $9F
[00494875] DB.TDataSet.DoInternalOpen + $19
[00494634] DB.TDataSet.Open + $4
[00558404] Provider.TCustomProvider.GetRecords + $58
[0055E698] Provider.TLocalAppServer.AS_GetRecords + $4C
[00568300] DBClient.TCustomClientDataSet.DoGetRecords + $94
[0056210A] DBClient.TCustomClientDataSet.InternalRefresh + $FE
[00496EFD] DB.TDataSet.Refresh + $35
[0080930C] ufrmEUS_BD_Davka1.TfrmEUS_BD_Davka1.actPostDokladExecute (Line 710, "ufrmEUS_BD_Davka1.pas" + 19) + $C
[0042A34B] Classes.TBasicAction.Execute + $F
[00457294] Controls.TControl.Perform + $24
[0045A384] Controls.TWinControl.IsControlMouseMsg + $80
[0045A16C] Controls.TWinControl.MainWndProc + $2C
[0042AFD4] Classes.StdWndProc + $14
[00477CE7] Forms.TApplication.ProcessMessage + $83
[00872FBC] ufrmEUS_HK_MAIN.TfrmEUS_HK_MAIN.actBD_PorizeniExecute (Line 2318, "ufrmEUS_HK_MAIN.pas" + 5) + $4
[0045A4EF] Controls.TWinControl.WndProc + $157
[0045A16C] Controls.TWinControl.MainWndProc + $2C
[0042AFD4] Classes.StdWndProc + $14
[00477CE7] Forms.TApplication.ProcessMessage + $83
[0087D6A4] EUS_HK.initialization (Line 308, "D:\Projects\EUS_HK\EUS_HK.dpr" + 5) + $7
{ _______End of the exception stact trace block_______ }

19.10.2010 11:55:18 { Original Exception - Katastrof

 

[Marco Kalter]

We have no fix yet, but the workaround is as suggested by Frantic:

My solution: I added critical section (Enter/Leave) into the InTransaction method.

 

[giga]

Thank you, but how can I do it if I have no source of DOA? Do I understand correctly that InTransaction is one of TORacleSession methods?
Another workaround?

Thank you very much.
V.