Mike,

I'm not sure using your components in such a stateful fashion might be the
best option, and, in reality, it won't work as you're doing it now.

The problem is that transaction lifetime in COM+ is tied to component
(object) lifetime (actually, to the context the root object of the
transaction lives in, but it's a non-essential distinction for our
discussion here). So, in other words, COM+ won't try to commit/rollback your
distributed transaction until *after* your component is deactivated (think
destroyed/released... unless you're using object pooling).

Given this, what's going on is this:
- You create your object, transaction is created (it might be created later,
but this works)
- You call a method on your object that does data access under the
transaction
- method sets member variable
- you deactivate the object without knowing (possibly you use [AutoComplete]
or use ContextUtil.SetComplete()/SetAbort())
- Object is released, COM+ commits/aborts transaction
- You try to access member property
- COM+ creates a new object under the hood and makes it look as if it was
the original one.... minus any state (this is possible because all
transactional objects support Just In Time Activation (JITA))

See the problem?

You can avoid this one of two ways:
1- Delay object deactivation: Don't use [AutoComplete] or
SetComplete()/SetAbort(). Instead just vote on the transaction in your
method by using ContextUtil.MyTransactionVote or
ContextUtil.EnableCommit()/DisableCommit(). That way you can call the method
and use the same object reference to access any state. However, now the
calling code is responsible for forcing object deactivation by either
explicitly disposing of the object or by calling a method on it that
triggers the deactivation. This is key, as otherwise the transaction will
linger open until the GC reclaims your object, killing
performance/scalability

2- Use something like the Shared Property Manager. This is ugly, not very
scalable, and possibly overkill.

My take is that you're really looking at something like 1, in which case I
strongly recommend taking a good look at the COM+ documentation on how JITA
works and how it affects transaction lifetime. Here's a good place to start:
*
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cossdk/html/dbc
7b257-8506-42c8-8a78-3474c6d4f4b6.asp
*
http://msdn.microsoft.com/library/en-us/cossdk/html/50086e6e-024b-4a09-b8be-8f55
b6bfadb2.asp?frame=true

A good book might also help; I recommend "Transactional COM+" by Tim Ewald.
He covers this issue in extreme detail, and its a great book all around on
building scalable systems.