AutoComplete attribute in Serviced Components-- how to use?

Thread view:

Enable EMail Alerts

Start New Thread

Thread rating:

Jim Bancroft - 13 Aug 2004 20:08 GMT

I'm having some trouble mixing "AutoComplete" attributes and transactions
with my VB .Net components.

Right now, I have two classes --a "parent" and "child"-- that inherit from
the .Net "ComponentServices" class. The parent class creates a new
transaction context (using a Transaction attribute) and calls the child
class, which participates in the transaction as it opens a SqlConnection to
a database and reads the contents of a table. Both classes have the
AutoComplete attribute set on them.

The problem for me comes when a transaction is supposed to fail. I've
modified my child class so that it tries opening an incorrectly-spelled
table, which triggers an exception. The Catch statement in the child
component is entered, but the transaction appears to complete, at least
according to the transaction statistics page in the COM+ explorer? As I
understand it, the AutoComplete attribute is supposed to abort the
transaction when an exception occurs, but it doesn't appear to be the case
here.

Am I missing a step or have I done something wrong? Do I have to vote
against the transaction my child class's exception handler, and if so,
doesn't that work against the notion of an AutoComplete attribute? Thanks
for your advice.

-Jim

Reply to this Message

Tomas Restrepo \(MVP\) - 14 Aug 2004 14:35 GMT

Jim,

> The problem for me comes when a transaction is supposed to fail. I've
> modified my child class so that it tries opening an incorrectly-spelled
[quoted text clipped - 4 lines]
> transaction when an exception occurs, but it doesn't appear to be the case
> here.

Actually, it is supposed to abort the transaction when the method actually
"throws" an exception (that is, when the exception is not handled internally
by the method and bubbles up outside of it's scope), not merely when the
exception occurs. If the child class handles the exception internally, COM+
will never see it, and thus it will never doom the transaction.

Furthermore, an exception would actually have to bubble up all the way out
of the outer component, since otherwise, you'll get the infamous
"transaction wanted to commit but transaction rolled back" error...

Signature

Tomas Restrepo
tomasr@mvps.org

Reply to this Message

Jim Bancroft - 16 Aug 2004 18:58 GMT

Thanks for the clarification, Tomas.

I'm a little confused with the ramifications however, and wondered if you
could suggest a way to deal with the situation? Right now it sounds like my
exception handler is getting in the way, almost-- I get an error, catch it
in the handler, and then the COM+ transaction continues along its merry way,
even though it shouldn't. Is the "proper" procedure here to manually vote
against the transaction in my handler, or are there better ways of going
about this?

Appreciate the help,

--Jim

> Jim,
>
[quoted text clipped - 16 lines]
> of the outer component, since otherwise, you'll get the infamous
> "transaction wanted to commit but transaction rolled back" error...

Reply to this Message

Tomas Restrepo \(MVP\) - 17 Aug 2004 02:02 GMT

Hi Jim,

> I'm a little confused with the ramifications however, and wondered if you
> could suggest a way to deal with the situation? Right now it sounds like my
[quoted text clipped - 3 lines]
> against the transaction in my handler, or are there better ways of going
> about this?

Yes, and no.
Yes, an option would be to explicitly doom the transaction from your
handler. That's a good practice, anyway (you can use ContextUtil.SetAbort()
for that or any other option, for that).

That said, you still need to ensure that the calling component knows that
your child component is dooming the transaction, otherwise, nasty errors
that are very hard to track down can appear. Consider, for example, the case
when Component A (parent) calls Component B, which silently dooms the
transaction, and then A goes on and tries to create component C on the same
transaction. or it tries to open up a new DB connection. That will fail with
wierd errors like "transaction cannot be null"; or cannot enlist on a
transaction already commited or aborted, or things like that.

Believe me, you don't want to find yourself in that situation ;) Play it
safe: catch the exception, do what you want, the bubble it up.

Signature

Tomas Restrepo
tomasr@mvps.org

Reply to this Message

Rate this thread:

AutoComplete attribute in Serviced Components-- how to use?

Free Magazines