orageneric8.dll AV

[edhamlin]

I have seen some old posts on this but need to raise it again and ask URGENTLY for advice. We are getting an intermittent but frequent AV in orageneric8.dll--it's killing us with a major customer.

We're running Oracle 8.1.7; the app is a Delphi 5 ISAPI app running under IIS; DOA 3.4.5. The app has a manager component that has a dedicated datamodule with an OracleSession; it manages a changeable number of child objects, each of which has a similar datamodule with its own OracleSession. The creation of the child object (and thereby their oracle sessions) is done inside a critical section, but logon and logoff of the individual oraclesessions is handled largely by the child objects; within the child object it's blocked in critsecs, but multiple child objects could be logging on/off simultaneously from the viewpoint of the Oracle client (I suppose).

I saw some comments on an earlier thread to the effect that mutexing the OracleSession connection process and/or using one shared connection might resolve it. The second is easier to implement; should I be worried about a bottleneck through that connection if I have 100 queries (owned by different child objects) competing for it? Also, if I do that I assume the TOracleSession.ThreadSafe property should be set true?

ANY IDEAS WELCOME! We're stumped and at our wit's end.

 

[Marco Kalter]

If you upgrade to the current 3.4.6 version and set TOracleSession.ThreadSafe to True, the logon/logoff processes will be performed within a global critical section.

I don't think this should affect performance, but if it does, then you probably have too many logon/logoff activity in your application, and you may want to implement some session reuse concept (e.g. pooling).

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

 

[edhamlin]

Thanks, Marco. Since posting this topic I reverted to having all my child objects share a single TOracleSession and run all their traffic through it. So far no more orageneric8.dll error--we're only logging on once, ever--and we're monitoring load/performance on that single connection.