All my MTS Classes are using this setting NotAnMTSObject and they seem to
run fine under MTS...

These are not transactional componants and do not require SetAbort and the
like....

Should they be set to NoTransactions instead...  What difference would it
make?

The NotAnMTSObject is pretty much the same as NoTransactions (as MTS sees
it) the difference is simply from a developers perspective that something
which says it isn't an MTS object should not sit under MTS, whereas
something that doesn't use transactions is obviously an MTS component which
doesn't require wrapping up in a transaction.

HTH

I've been led to believe that one of the benefits of wrapping things in MTS
packages is that the components can be upgraded/replaced without first stopping
IIS, which otherwise tends not to let go without a reboot of the server.  The
idea is that MTS terminates the component as soon as the calling context has
done with it, making management easier.  If this is not the case, I'd be
interested in more information (in this area, I am only an egg).

True, this does make the management easier, but in my line of work, we
generally have to shut everything down to do an update anyway, I believe
this is probably the case with most "live" systems.

Hi Kip,
Chris was right. The object comes to the idle state after you release the reference to it (after you release it at the end). Not when you're still holding on to it. Correct me if I'm wrong.

      Trevor Benedict R

      Software Consultant
      Mastech Malaysia Sdn Bhd

  If objects are shut down after three minutes what happens to obects that are
  declared  at the beginning of the client application and released at the
  end?

  > You can set the life time of an object, I think the default is three
  > minutes, MTS/COM+ shuts a created object down if it's left idle for those
  > three minutes.  After MTS has shut the object down you can quickly
  overwrite
  > it with your new version.
  >
  > True, this does make the management easier, but in my line of work, we
  > generally have to shut everything down to do an update anyway, I believe
  > this is probably the case with most "live" systems.
  >
  > Chris.Heywood

  >


  > > Chris
  > >
  > > I've been led to believe that one of the benefits of wrapping things in
  > MTS
  > > packages is that the components can be upgraded/replaced without first
  > stopping
  > > IIS, which otherwise tends not to let go without a reboot of the server.
  > The
  > > idea is that MTS terminates the component as soon as the calling context
  > has
  > > done with it, making management easier.  If this is not the case, I'd be
  > > interested in more information (in this area, I am only an egg).
  > >

  > >
  > > > MTS is there mainly to allow (as it's name suggests) for a higher
  level
  > of
  > > > transaction control, it also gives some nice functionality for pooling
  > and
  > > > sharing of properties.  If you do not use transactions in your
  > components I
  > > > would suggest not using MTS, even though your component may be easier
  to
  > > > install, it places quite a large overhead on you DLL regardless of
  > whether
  > > > they are set to use transactions or not.
  > > >
  > > > The NotAnMTSObject is pretty much the same as NoTransactions (as MTS
  > sees
  > > > it) the difference is simply from a developers perspective that
  > something
  > > > which says it isn't an MTS object should not sit under MTS, whereas
  > > > something that doesn't use transactions is obviously an MTS component
  > which
  > > > doesn't require wrapping up in a transaction.
  > > >
  > > > HTH
  > > >
  > > > Chris.Heywood

  > > >


  > > > >
  > > > > All my MTS Classes are using this setting NotAnMTSObject and they
  seem
  > to
  > > > > run fine under MTS...
  > > > >
  > > > > These are not transactional componants and do not require SetAbort
  and
  > the
  > > > > like....
  > > > >
  > > > > Should they be set to NoTransactions instead...  What difference
  would
  > it
  > > > > make?
  > > > >
  > > > >
  > > > >
  > >
  >
  >

Ok, so then why wouldn't it be destroyed right away?  If it is idle and the reference is lost...

  Hi Kip,
  Chris was right. The object comes to the idle state after you release the reference to it (after you release it at the end). Not when you're still holding on to it. Correct me if I'm wrong.

        Trevor Benedict R

        Software Consultant
        Mastech Malaysia Sdn Bhd

    If objects are shut down after three minutes what happens to obects that are
    declared  at the beginning of the client application and released at the
    end?

    > You can set the life time of an object, I think the default is three
    > minutes, MTS/COM+ shuts a created object down if it's left idle for those
    > three minutes.  After MTS has shut the object down you can quickly
    overwrite
    > it with your new version.
    >
    > True, this does make the management easier, but in my line of work, we
    > generally have to shut everything down to do an update anyway, I believe
    > this is probably the case with most "live" systems.
    >
    > Chris.Heywood

    >


    > > Chris
    > >
    > > I've been led to believe that one of the benefits of wrapping things in
    > MTS
    > > packages is that the components can be upgraded/replaced without first
    > stopping
    > > IIS, which otherwise tends not to let go without a reboot of the server.
    > The
    > > idea is that MTS terminates the component as soon as the calling context
    > has
    > > done with it, making management easier.  If this is not the case, I'd be
    > > interested in more information (in this area, I am only an egg).
    > >

    > >
    > > > MTS is there mainly to allow (as it's name suggests) for a higher
    level
    > of
    > > > transaction control, it also gives some nice functionality for pooling
    > and
    > > > sharing of properties.  If you do not use transactions in your
    > components I
    > > > would suggest not using MTS, even though your component may be easier
    to
    > > > install, it places quite a large overhead on you DLL regardless of
    > whether
    > > > they are set to use transactions or not.
    > > >
    > > > The NotAnMTSObject is pretty much the same as NoTransactions (as MTS
    > sees
    > > > it) the difference is simply from a developers perspective that
    > something
    > > > which says it isn't an MTS object should not sit under MTS, whereas
    > > > something that doesn't use transactions is obviously an MTS component
    > which
    > > > doesn't require wrapping up in a transaction.
    > > >
    > > > HTH
    > > >
    > > > Chris.Heywood

    > > >


    > > > >
    > > > > All my MTS Classes are using this setting NotAnMTSObject and they
    seem
    > to
    > > > > run fine under MTS...
    > > > >
    > > > > These are not transactional componants and do not require SetAbort
    and
    > the
    > > > > like....
    > > > >
    > > > > Should they be set to NoTransactions instead...  What difference
    would
    > it
    > > > > make?
    > > > >
    > > > >
    > > > >
    > >
    >
    >

There are caveats in the documentation, on the lines that if
objects have unresolved references or references to other
objects they have not themselves shut down, and especially
if there's a circular reference back to the object itself,
you may never get the thing to go away.  All this makes
sense, but one has this niggling doubt that there is, shall
we say, an undocumented feature somewhere which keeps
objects alive past their time.  Now if only I could find out
what it is, and apply it to me ...

Others explain things better than I so here is an extract from

http://tech.indiainfo.com/technology/digital/tech/Work.html

For MTS-compliant (that is, stateless) components, MTS maintains a pool of objects of the same type as requested by the object client. Since these components are MTS compliant (stateless), MTS can afford to execute one client request from one object instance in the pool, while executing another client request from another object instance. These object instances are kept alive by MTS, even after a client disconnects from the object, and the connection between the client and the context wrapper which encapsulates the object is broken.This helps it scale such components because, when a new request from some other client comes in for the same object, instead of reactivating and instantiating the object again, MTS simply creates a context wrapper which links the client to the object and client requests are fulfilled using the object instances from the pool maintained by MTS. Also, such components can tell MTS when they're through with a request, so that MTS can free that instance for use by some other client.

On the other hand, MTS can't maintain the pool for stateful objects since they're unaware of MTS, and hence can't tell MTS when they're done. Moreover, since they maintain their state between instances, MTS can't afford to fulfill one client request from one instance and another from another instance.

HTH

  Ok, so then why wouldn't it be destroyed right away?  If it is idle and the reference is lost...

    Hi Kip,
    Chris was right. The object comes to the idle state after you release the reference to it (after you release it at the end). Not when you're still holding on to it. Correct me if I'm wrong.

          Trevor Benedict R

          Software Consultant
          Mastech Malaysia Sdn Bhd

      If objects are shut down after three minutes what happens to obects that are
      declared  at the beginning of the client application and released at the
      end?

      > You can set the life time of an object, I think the default is three
      > minutes, MTS/COM+ shuts a created object down if it's left idle for those
      > three minutes.  After MTS has shut the object down you can quickly
      overwrite
      > it with your new version.
      >
      > True, this does make the management easier, but in my line of work, we
      > generally have to shut everything down to do an update anyway, I believe
      > this is probably the case with most "live" systems.
      >
      > Chris.Heywood

      >


      > > Chris
      > >
      > > I've been led to believe that one of the benefits of wrapping things in
      > MTS
      > > packages is that the components can be upgraded/replaced without first
      > stopping
      > > IIS, which otherwise tends not to let go without a reboot of the server.
      > The
      > > idea is that MTS terminates the component as soon as the calling context
      > has
      > > done with it, making management easier.  If this is not the case, I'd be
      > > interested in more information (in this area, I am only an egg).
      > >

      > >
      > > > MTS is there mainly to allow (as it's name suggests) for a higher
      level
      > of
      > > > transaction control, it also gives some nice functionality for pooling
      > and
      > > > sharing of properties.  If you do not use transactions in your
      > components I
      > > > would suggest not using MTS, even though your component may be easier
      to
      > > > install, it places quite a large overhead on you DLL regardless of
      > whether
      > > > they are set to use transactions or not.
      > > >
      > > > The NotAnMTSObject is pretty much the same as NoTransactions (as MTS
      > sees
      > > > it) the difference is simply from a developers perspective that
      > something
      > > > which says it isn't an MTS object should not sit under MTS, whereas
      > > > something that doesn't use transactions is obviously an MTS component
      > which
      > > > doesn't require wrapping up in a transaction.
      > > >
      > > > HTH
      > > >
      > > > Chris.Heywood

      > > >


      > > > >
      > > > > All my MTS Classes are using this setting NotAnMTSObject and they
      seem
      > to
      > > > > run fine under MTS...
      > > > >
      > > > > These are not transactional componants and do not require SetAbort
      and
      > the
      > > > > like....
      > > > >
      > > > > Should they be set to NoTransactions instead...  What difference
      would
      > it
      > > > > make?
      > > > >
      > > > >
      > > > >
      > >
      >
      >