Not declaring the AutoComplete attribute in

Thread view:

Enable EMail Alerts

Start New Thread

Thread rating:

CricketWee - 21 Sep 2004 07:20 GMT

Hi all,

I'm encountering an error at work which might be the cause of my "ORA-
24761: transaction rolled back" problem and am wondering whether there
are others who may have encountered this.

Our C# classes use COM+ to manage transactions and we also employ the
Microsoft Enterprise Templates as prescribed in VS.NET. The business
facade classes are our transaction root with most of them having the
Transaction.Required attribute set. However, not all methods within the
business facade classes have the AutoComplete attribute.

Currently we have the following flow:

BF.A -> BF.B -> BF.C -> BF.D -> BR.D - DA.D -> Oracle DataAdapter

BF = Business Facade Classes
BR = Business Rules Classes
DA = Data Access Classes

- BF.B's method is the only one with the AutoComplete attribute set
- BF.A's method is trying to query of some information that belongs to
another module.

The questions I have is:
1. Is it okay to omit the AutoComplete Attribute and not call SetComplete
or SetAbort?

2. Has anybody done something similar to what I've done and encountere
the above error

We're using
- Oracle 9i Database
- Oracle .NET Data Provider 9.2.0.4.01
- Oracle Service for Micrsoft Transaction Server 9.2.0.4.0
- .NET Framework 1.1
- Windows 2000 Server

This ORA-24761 error seems to be random and not repeatable as far as I
can tell.

Any suggestions would be very helpful at this point.

Many thanx in advance :)

Terence

Reply to this Message

Michael D. Long - 22 Sep 2004 02:10 GMT

This sounds like it could be bug # 2824408. You'll need a Metalink login to
look it up, or you can contact Oracle Support.

Signature

Michael D. Long

> Hi all,
>
[quoted text clipped - 42 lines]
>
> Terence

Reply to this Message

CricketWee - 23 Sep 2004 15:45 GMT

Hi Michael,

Got my DBA to check up on the bug you mentioned. Apparently that bug was
solved with the realise of ODP.NET 9.2.0.4. :(

Will keep looking I guess.

Thanx,
Terence

> This sounds like it could be bug # 2824408. You'll need a Metalink
> login to look it up, or you can contact Oracle Support.

Reply to this Message

Ed - 24 Sep 2004 16:23 GMT

If [Transaction.Required] component method has no [AutoComplete] attribute
and do not call SetComplete method, its transaction will never complete and
will be aborted after transaction timeout period.

> Hi all,
>
[quoted text clipped - 42 lines]
>
> Terence

Reply to this Message

Tomas Restrepo \(MVP\) - 25 Sep 2004 14:37 GMT

Ed,

> If [Transaction.Required] component method has no [AutoComplete] attribute
> and do not call SetComplete method, its transaction will never complete and
> will be aborted after transaction timeout period.

That's not exactly true. if the client disposes the component as appropriate
by calling IDisposable::Dispose() or ServicedComponent::DisposeObject(),
that will deactivate the component and trigger the commit/rollback.

Signature

Tomas Restrepo
tomasr@mvps.org

Reply to this Message

Ed - 27 Sep 2004 13:49 GMT

Tomas,

> That's not exactly true. if the client disposes the component as appropriate
> by calling IDisposable::Dispose() or ServicedComponent::DisposeObject(),
> that will deactivate the component and trigger the commit/rollback.

So if the client makes several calls to transactional component which
doesn't have [AutoComplete] and after it invokes Dispose() (which is a normal
pattern of COM+ components using, isn't it), all these transactions will
commit/rollback immediatedly after Dispose()?

Ed

Reply to this Message

Tomas Restrepo \(MVP\) - 28 Sep 2004 00:42 GMT

Hi Ed,

> So if the client makes several calls to transactional component which
> doesn't have [AutoComplete] and after it invokes Dispose() (which is a normal
> pattern of COM+ components using, isn't it), all these transactions will
> commit/rollback immediatedly after Dispose()?

Maybe, maybe not... it depends on whether the object in question is the root
of the transaction stream.

Let me put it all this way:

While a transaction can spawn multiple contexts, the first context it was
created in is known as the root of the transaction stream. Regardless of how
many components are involved in the transaction, and how many of them vote
on the transaction, COM+ will only decide to try to commit or try to
rollback the transaction *after* it deactivates the object in the context
that is the root of the transaction stream (that's why the object itself can
never know the result of the transaction!).

Now, there are several ways the object could be deactivated:
1- It uses [AutoComplete], in which case COM+ will deactivate the component
right after the call to the method exits (and COM+ will decide whether to
commit or rollback depending on the state of the transaction so far, and
whether the method threw an exception or returned normally).
2- It does *not* use [AutoComplete], but rather uses
ContextUtil.SetComplete()/SetAbort() or sets ContextUtil.DeactivateOnReturn
= true.
3- The object itself doesn't do any of the two above, but rather lets the
caller decide when to do so. The caller decides by releasing all references
to the object (in COM terms), which in .NET is done by calling
IDisposable::Dispose() or ServicedComponent::DisposeObject().

Is that any clearer?

Signature

Tomas Restrepo
tomasr@mvps.org

Reply to this Message

Rate this thread:

Not declaring the AutoComplete attribute in

Free Magazines