Transaction context handling in COM+/.NET
Thomas Heder
again...
If I create a class inheriting from ServicedComponent, this component will
get a transactional context. If I in a method in this class instantiate
objects *not* deriving from Serviced component - these objects will
apparently also participate in the transaction. (I have tested and verified
this). So - the transaction context get "passed" over to objects created
from the "first" object even if they are not inheriting from
ServicedComponent, So far - so good... This is the way i would like it to
work..
But... browsing MSDN I found this article:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndotnet/ht
ml/entserv.asp
The author states the following about objects not inheriting from
ServicedComponent in COM+
"Relying on this is dangerous and in future versions the unmanaged context
may merge with the managed context and therefore the child objects will be
associated with a potentially different managed context; the resource
managers will not pick up the root object's context. Therefore, upgrading to
a new version of .NET could break code that depends on this type of
behavior."
Could anyone comfirm or deny that this is true?
Regards!
//Thomas Heder
Aldo Pahor
in my opinion, if your child object is full context-agile managed objects
then it will be always loaded in the caller context and you are ok.
Full context-agile managed object means that the object does not derive from
any .net context bound class.
Aldo Pahor
"Thomas Heder" <thomas...@home.se> wrote in message
news:uqzoIn2dCHA.2504@tkmsftngp10...
David Yuan [MS]
provide a different context for the child object as well. I think in your
scenario, you'd better inherit your child object from ServicedComponnet,
but mark it as "Supported" for transaction, so that it can participate in
its father's transaction.
David Yuan [MS]
This posting is provided "AS IS" with no warranties, and confers no rights.
"Got .Net? http://www.gotdotnet.com".
Jimmy Nilsson
How is this possible change affecting my code if I use "Disabled" instead?
Best Regards,
Jimmy
###
"David Yuan [MS]" <sgy...@online.microsoft.com> wrote in message
news:rSq3JmAfCHA.1328@cpmsftngxa08...
Franci Penov [MSFT]
not transactional.
Why would you want to mark it Disabled, if you want to access the parent
transaction?
Franci Penov
.
--
Please do not send email directly to this alias. This alias is for newsgroup
purposes only.
This posting is provided "AS IS" with no warranties, and confers no rights.
"Jimmy Nilsson" <Jimmy.Nilsson@nospam_jnsk.se> wrote in message
news:ek8jB5CfCHA.1952@tkmsftngp09...
Franci Penov [MS]
As far as i know, the Disabled means that the object requires
non-transactional context. NotSupported means that the object does not
impose any requirement to the context, but if there is a transaction, it
will simply ignore it. Supported means that the object does not impose
requirements to the context, but it is transactional, the object will play
along with it and participate in the voting.
Franci Penov
.
--
Please do not send email directly to this alias. This alias is for newsgroup
purposes only.
This posting is provided "AS IS" with no warranties, and confers no rights.
"Jimmy Nilsson" <Jimmy.Nilsson@nospam_jnsk.se> wrote in message
news:#zVcBJFgCHA.2284@tkmsftngp11...
> Hi Franci,
>
> > If you use Disabled, the child object will be created in new context
that
> is
> > not transactional.
>
> I'm pretty sure that is wrong. Or perhaps I misunderstand you somehow?
> Using disabled tx is to take away one hinder so that the component will be
> instantiated within the context of the caller.
>
>
> > Why would you want to mark it Disabled, if you want to access the parent
> > transaction?
>
> Perf reasons and reduction of memory usage.
>
> Best regards,
> Jimmy
> ###
Jimmy Nilsson
> If you use Disabled, the child object will be created in new context that
is
> not transactional.
I'm pretty sure that is wrong. Or perhaps I misunderstand you somehow?
Using disabled tx is to take away one hinder so that the component will be
instantiated within the context of the caller.
> Why would you want to mark it Disabled, if you want to access the parent
> transaction?
Perf reasons and reduction of memory usage.
Best regards,
Jimmy
###
>
Franci Penov [MS]
--
Please do not send email directly to this alias. This alias is for newsgroup
purposes only.
This posting is provided "AS IS" with no warranties, and confers no rights.
"Tomas Restrepo [MVP]" <tom...@mvps.org> wrote in message
news:OAw7AJHgCHA.2068@tkmsftngp12...
> Franci,
>
> > As far as i know, the Disabled means that the object requires
> > non-transactional context. NotSupported means that the object does not
> > impose any requirement to the context, but if there is a transaction, it
> > will simply ignore it.
>
> Actually, it's the other way around.
>
> Not Supported means the object does not support a transactional context,
and
> thus if the creator is in one, a new, non-transactional context will be
> created for the new object.
>
> Disabled means Ignored, which means the new object will be in a
transaction
> only if it also gets created into the same context as its creator. This is
> more commonly used sometimes with MustRunInClientContext.
>
> --
> Tomas Restrepo
> tom...@mvps.org
>
Tomas Restrepo [MVP]
> [sigh] Of course, you are right. I always mix up these two.
Hey, no problem; Been there, done that :)
This is what we're all here in the newsgroups for :)
--
Tomas Restrepo
tom...@mvps.org
Peter Strřiman
even be sure how this object is created.
E.g. If I in a C++ ATL COM+ component would create a COM+ component that in
it's implementation detail uses a number of local classes - I would just
create these classes using the "new" keyword. From the view of COM+ - these
classes would just be part of my component implementation. The new keyword
would be handled 100% by the c++-runtime.
If I would create a global object that is initialized from som database
data - this object could participate in different transactions at the same
time - because it would be called from different COM+ components
simultaneously.
This private object could even vote for the outcome of the transaction using
"CoGetObjectContext"
I am actually in a situation where I need to implement this pattern in a
.net library. I want to have one global object (that has a child hierarchy
of objects) because it is initialized from the database with a lot of data -
but all the data is static. Thus the object itself is not dependand on state
in the individual transaction
But if I can't create an object and have it "act" as an implementation
detail of whatever Serviced Component is accessing it - MS is putting a
serious barrier on our freedom of technique to implement our serviced
components.
Regards,
Peter Strřiman
"David Yuan [MS]" <sgy...@online.microsoft.com> wrote in message
news:rSq3JmAfCHA.1328@cpmsftngxa08...
Craig Critchley [MS]
will run in their caller's context and can use ContextUtil to obtain or vote
on the transaction outcome. They are context-agile.
So you can do exactly what you describe.
...Craig
--
Please do not send email directly to this alias. This alias is for newsgroup
purposes only.
This posting is provided "AS IS" with no warranties, and confers no rights.
"Peter Strřiman" <blab...@blablabla.com> wrote in message
news:#oxYPLkhCHA.2288@tkmsftngp12...
Jimmy Nilsson
the rules about contexts might change in future .NET versions. That was also
mentioned in a white paper by Shannon Pahl.
Best Regards,
Jimmy
###
"Craig Critchley [MS]" <xws...@online.microsoft.com> wrote in message
news:e3M2UqphCHA.2672@tkmsftngp09...
Peter Strřiman
I was commenting on the fact, that the article mentioned in the original
post of this thread specifies that this kind of implementation maight change
behaviour in the future. I very much disagree with that.
Regards,
Peter Strøiman
"Jimmy Nilsson" <Jimmy.Nilsson@nospam_jnsk.se> wrote in message
news:#EQ8iSqhCHA.2400@tkmsftngp08...
> I think what Peter was referring to was the information from David Yuan
that
> the rules about contexts might change in future .NET versions. That was
also
> mentioned in a white paper by Shannon Pahl.
>
> Best Regards,
> Jimmy
> ###
>
>
> "Craig Critchley [MS]" <xws...@online.microsoft.com> wrote in message
> news:e3M2UqphCHA.2672@tkmsftngp09...
> > Objects which do not derive from ServicedComponent or ContextBoundObject
> > will run in their caller's context and can use ContextUtil to obtain or
> vote
> > on the transaction outcome. They are context-agile.
> >
> > So you can do exactly what you describe.
> >
> > ...Craig
> >
> > --
> > Please do not send email directly to this alias. This alias is for
> newsgroup
> > purposes only.
> > This posting is provided "AS IS" with no warranties, and confers no
> rights.
> >
> >
> > "Peter Strøiman" <blab...@blablabla.com> wrote in message
> > > Peter Strøiman
Jimmy Nilsson
> Eaxactly.
> I was commenting on the fact, that the article mentioned in the original
> post of this thread specifies that this kind of implementation maight
change
> behaviour in the future. I very much disagree with that.
I guess both you and I are worried since we are lacking information. I'll
ask Shannon to jump in here and discuss it with us.
Best Regards,
Jimmy
###
Craig Critchley [MS]
believe we could change context-agile objects into context-bound objects -
it changes their behaviour in fundamental ways. For one thing, context
bound objects are marshal-by-ref.
There are classes in the frameworks which are not context bound but which do
reference the context: SqlConnection, for one.
I believe this is merely an unfortunate misunderstanding. If you could
point out the whitepaper you are looking at and what's confusing about it, I
would appreciate it.
...Craig
--
Please do not send email directly to this alias. This alias is for newsgroup
purposes only.
This posting is provided "AS IS" with no warranties, and confers no rights.
"Jimmy Nilsson" <Jimmy.Nilsson@nospam_jnsk.se> wrote in message
news:eJCv6axhCHA.4088@tkmsftngp08...
Craig Critchley [MS]
was not about the possibility of agile objects becoming context bound, it
was about the differences between CLR ContextBoundObject and
ServicedComponent, which is derived from ContextBoundObject but has an
unmanaged COM+ context associated with it. You can imagine that if an
all-managed ServicedComponent were written then the context associated with
a component would be a managed CLR Context instead of a COM+ context. That
has *nothing* to do with agile, objects, however - that has only to do with
ContextBoundObjects.
You can safely write agile objects with the expectation that they will
remain agile in the future. Also, ContextBoundObject is not much used
besides ServicedComponent at the moment, so you don't need to worry too much
about stumbling over a ContextBoundObject in the frameworks classes, either.
I apologize for any confusion this may have caused.
...Craig
--
Please do not send email directly to this alias. This alias is for newsgroup
purposes only.
This posting is provided "AS IS" with no warranties, and confers no rights.
"Craig Critchley [MS]" <xws...@online.microsoft.com> wrote in message
news:uBEbot3hCHA.2544@tkmsftngp11...
Peter Strřiman
I have included the paragraph in question later in this post
As I understand your previous post, the context agile components mentioned
in the paper are actually components derived from ContextBoundObject? This
is not mentioned in the text, thus I read it as the context agile components
are simply classes not derived from anything. Is this the cause of the
confusion?
Is the meaning of the text this?
"If you have a class derived from ContextBoundObject and expect it to be
context agile, this might change in the future and upgrading to future
versions of .NET could break your code."
But if you define a class not derived from anything (implicitly derived from
Object) then it would be truly context agile both now and in the future?
Thanks in advance.
Section of text from original MS article:
Contexts
The class ContextUtil is used to access the associated COM+ object context
and its properties. This provides similar functionality as the object
returned by CoGetObjectContext in unmanaged code. The managed object context
associated with a serviced component serves a different purpose than the
associated unmanaged object context. This is manifested by writing three
managed objects, one with Transactions required (acting as the root), the
other two not deriving from serviced component (acting as child objects
exemplifying context-agile managed objects). The non-serviced components
will behave as if they were serviced components with Transactions supported,
that is, they can make calls to resource managers and use
ContextUtil.SetAbort if needed. When the root object gets created, the
associated unmanaged context is created and associated with the current
thread. When a call to the child objects is made, since they are not
associated with an unmanaged context, no COM+ context change is needed,
hence the thread still maintains the root's unmanaged context id. When a
child object calls on resource managers, the resource managers will in turn
extract the unmanaged context from the thread executing the child object,
which is the root object's unmanaged context. Relying on this is dangerous
and in future versions the unmanaged context may merge with the managed
context and therefore the child objects will be associated with a
potentially different managed context; the resource managers will not pick
up the root object's context. Therefore, upgrading to a new version of .NET
could break code that depends on this type of behavior.
"Craig Critchley [MS]" <xws...@online.microsoft.com> wrote in message
news:OLr2Oe4hCHA.1308@tkmsftngp11...
Craig Critchley [MS]
contexts in COM+. Agile objects are not derived from ContextBoundObject,
they just inherit from Object. ServicedComponents are context bound, and
derived from ContextBoundObject, but they are bound to COM+ contexts rather
than CLR contexts.
A managed ContextBoundObject which is not a ServicedComponent is, currently,
agile with respect to COM+ contexts. It's still bound to a CLR context. It
is possible in the future that this will change, if the COM+ context becomes
a managed context.
If you aren't derived from ContextBoundObject you can expect to remain agile
with respect to either.
Happy to help,
...Craig
--
Please do not send email directly to this alias. This alias is for newsgroup
purposes only.
This posting is provided "AS IS" with no warranties, and confers no rights.
"Peter Strřiman" <blab...@blablabla.com> wrote in message
news:eb0LXGliCHA.1840@tkmsftngp08...
Thomas Heder
step in to thank you all folks for making this clear to me (and everyone
else). This thread ultimately lead to exactly the answer(s) I was looking
for in the first place!
//Thomas Heder
Benima Mellan AB, Sweden
"Craig Critchley [MS]" <xws...@online.microsoft.com> wrote in message
news:eDHenhriCHA.1616@tkmsftngp10...
Jimmy Nilsson
question?
The possible future change won't affect how serviced components that are
colocated within the caller's context works regarding tx and such, right?
And not either how those that are located in the default context works? I
just wanted to be sure.
Best Regards,
Jimmy
###
"Thomas Heder" <thomas...@home.se> wrote in message
news:#lBWQDuiCHA.2536@tkmsftngp12...