DOA 4.0.7.1 and com+ not working with Oracle 10 client

[Pim-Jan Veenendaal]

We recently upgraded our com+ application from DOA 4.0.3 on an Oracle 8 client to DOA 4.0.7.1. First using the Oracle 8.1.7 client, and now using an Oracle 10.2.0.1.0 client.

Our application ran just fine on the Oracle 8 client but on the Oracle 10 client, we ran into errors in the TOracleSession.LogOn procedure: "MTS Error 1002: Failure to create dispen in function OraMtsSvcGet". This happens after we raise an error somewhere during a transaction with multiple connections and another application (or the same application for another request) starts with a LogOn.

Every query runs in its own thread with its own TOracleSession and TOracleQuery. Pooling is spMTS, ThreadSafe is False, UseSingleEnvironment is False. After the data is fetched, the query and the session are freed.

Any suggestions on how to analyze this problem or how to fix it without compromising performance?

Pim-Jan

 

[Marco Kalter]

I can find one additional problem report like this, where the cause was the number of simultaneous transactions. Could this be the cause here as well?

 

[Pim-Jan Veenendaal]

It is reproducable with one active transaction. In one case multiple connections (one database, multiple users and datasets) are involved, in another case one connection is involved and one other resource manager (no database). The transaction is always aborted due to a functional error (expected data not found, insufficient application privileges). There is no problem when transactions are committed.

Do you have a link to that report you can give me?

Pim-Jan

 

[Marco Kalter]

I looked it up, and it was reported on June 14, 2000, by a (former?) colleague of yours: Ewart Nijburg. Is he still around ?

 

[Pim-Jan Veenendaal]

Hi Marco,

Ewart left the company several years ago. I could not find his report you mentioned. Do you have a direct url?

Any suggestions on how to analyze or isolate the problem?

Pim-Jan

 

[Pim-Jan Veenendaal]

Marco,

I tried some other error handling mechanism in TOracleSession. According to the Oracle documentation there is a function OraMTSOCIErrGet that retrieves the last OCI errr in case an MTS function (like OraMTSSvcGet) fails. So I imported this function and changed TOracleSession.MTSCall:

if Error ORAMTSERR_NOERROR then
begin
if OraMTSOCIErrGet(ErrCode, Buffer, BufferSize) then raise Exception.CreateFmt('OraMTSOCIErrGet repots error %d: %s', [ErrCode, StrPas(Buffer)])
else raise EOraMTSError.Create(FunctionName, Error, False);
end;

Of course ErrCode, Buffer and BufferSize are allocated correctly.

So instead of the MTS Error 1002 I received a "ORA-24761: Transaction rolled back" error (the same error appears in the OCI client-side trace file). This type of error is raised when the server-side transaction has been rolled back and the client issues a commit. But where does the commit come from? Not from me, the TOracleSession.Commit is blocked while working with MTS transactions.

It appears that the MTS Error 1002 is like a general error for a failure in getting a connection (invalid password, tns error, etc.). The underlying OCI call is more interesting.

Pim-Jan

 

[Marco Kalter]

Hmm, we'll enhance that.

 

[Pim-Jan Veenendaal]

I isolated the problem by programming directly on the Oracle API. It seams that a connection that was involved in an aborted transaction (a "transaction required" component) cannot be used in a non-transactional ("transaction supported") call (same user/pwd/server combination).
It's easy to reproduce (also with DOA) and I do not think that it can be solved by changing a property or a setting in DOA or in our code. So I suppose we will call Oracle support.

Pim-Jan

 

[Pim-Jan Veenendaal]

The problem was reproduced by Oracle support. Applying a patch for oramts10.dll (Oracle reference 5410059) appears to fix the problem.

Pim-Jan