Component will not create a new transaction

[Alan]

Gidday people,

I had a bit of a problem this morning. I think I've got it sorted now, but I
wonder if anyone can shed some light.

I have a plain VBS WHS file that instantiates a component that controls an
interface file import process. This component, Controller, is part of
FinInterface.dll, and instantiates another component, Implementor (same
dll), that does the actual data access (an insert into a FinanceDataImports
table, and then multiple inserts into a child FinanceData table).

All the data access logic is in the Implementor class so I set the
MTSTransactionMode on this component to RequiresTransaction and did all the
right things with ObjectContext. I left the MTSTransactionMode set to
NotAnMTSObject for Controller class.

I created a new COM+ Services library application, configured *just* the
Controller class and thought I was away laughing.

To cut a long story short, during my testing I noticed that my transactions
weren't rolling-back (when I created error conditions). I tried heaps of
things, all the MTSTransactionMode settings on the Implementor class,
switching from Library to Server applications, configured and unconfigured
modes, and every time I found that the Implementor class would not run in a
transaction. I verified this by inserting a call to
mObjectContext.IsInTransaction() and raising an error if it returned False -
which it did - every time.

I sorted it out by also setting the MTSTransactionMode to
RequiresTransaction on the Controller class, and installing *both*
Controller and Implementor in the COM+ Services library application. Even
though the Controller object doesn't use the ObjectContext specifically (it
never calls GetObjectContext(), SetAbort(), SetComplete() or does any
database work), I guess the transaction is created when the first object
(Controller) is instantiated, and then it's used by the Implementor object.

I must admit this caught me a bit by surprise. I thought that any component
could get a reference to it's own ObjectContext regardless of how it's
instantiated. It looks like Implementor will only run in a transaction if
the calling component is configured as an MTS object, even if that first
object doesn't need a transaction.

Thanks for reading to the end. I hope I explained things well enough. Does
anyone have any thoughts on the behaviour here?

Cheers,

Alan

[Vlad Vissoultchev]

do you use CreateObject to create objects?

you can't use New keyword and get the coclass creation interception COM+ is
doing. you have to go CreateObject (or CreateInstance) all the way through
COM libs.

New in VB is using a shortcut to create objects with a simple call to
object's constructor, jumping over all the COM (COM+) interception code.

HTH,
</wqw>
"Alan" <SP******************@inspire.net.nz> wrote in message
news:uk*************@TK2MSFTNGP12.phx.gbl...

Gidday people,

I had a bit of a problem this morning. I think I've got it sorted now, but I wonder if anyone can shed some light.

I have a plain VBS WHS file that instantiates a component that controls an
interface file import process. This component, Controller, is part of
FinInterface.dll, and instantiates another component, Implementor (same
dll), that does the actual data access (an insert into a FinanceDataImports table, and then multiple inserts into a child FinanceData table).

All the data access logic is in the Implementor class so I set the
MTSTransactionMode on this component to RequiresTransaction and did all the right things with ObjectContext. I left the MTSTransactionMode set to
NotAnMTSObject for Controller class.

I created a new COM+ Services library application, configured *just* the
Controller class and thought I was away laughing.

To cut a long story short, during my testing I noticed that my transactions weren't rolling-back (when I created error conditions). I tried heaps of
things, all the MTSTransactionMode settings on the Implementor class,
switching from Library to Server applications, configured and unconfigured
modes, and every time I found that the Implementor class would not run in a transaction. I verified this by inserting a call to
mObjectContext.IsInTransaction() and raising an error if it returned False - which it did - every time.

I sorted it out by also setting the MTSTransactionMode to
RequiresTransaction on the Controller class, and installing *both*
Controller and Implementor in the COM+ Services library application. Even
though the Controller object doesn't use the ObjectContext specifically (it never calls GetObjectContext(), SetAbort(), SetComplete() or does any
database work), I guess the transaction is created when the first object
(Controller) is instantiated, and then it's used by the Implementor object.
I must admit this caught me a bit by surprise. I thought that any component could get a reference to it's own ObjectContext regardless of how it's
instantiated. It looks like Implementor will only run in a transaction if
the calling component is configured as an MTS object, even if that first
object doesn't need a transaction.

Thanks for reading to the end. I hope I explained things well enough. Does
anyone have any thoughts on the behaviour here?

Cheers,

Alan

[Alan]

The Controller object is instantiated using CreateObject in the WSH script,
and then instantiates the Implementor object using the New keyword. Should I
try changing the Controller class to CreateObject/CreateInstance the
Implementor object?

Thanks for the reply.

Alan

"Vlad Vissoultchev" <wq****@nospam.myrealbox.com> wrote in message
news:er**************@tk2msftngp13.phx.gbl...

do you use CreateObject to create objects?

you can't use New keyword and get the coclass creation interception COM+ is doing. you have to go CreateObject (or CreateInstance) all the way through
COM libs.

New in VB is using a shortcut to create objects with a simple call to
object's constructor, jumping over all the COM (COM+) interception code.

HTH,
</wqw>
"Alan" <SP******************@inspire.net.nz> wrote in message
news:uk*************@TK2MSFTNGP12.phx.gbl...

Gidday people,

I had a bit of a problem this morning. I think I've got it sorted now, but

I

wonder if anyone can shed some light.

I have a plain VBS WHS file that instantiates a component that controls

an interface file import process. This component, Controller, is part of
FinInterface.dll, and instantiates another component, Implementor (same
dll), that does the actual data access (an insert into a

FinanceDataImports

table, and then multiple inserts into a child FinanceData table).

All the data access logic is in the Implementor class so I set the
MTSTransactionMode on this component to RequiresTransaction and did all

the

right things with ObjectContext. I left the MTSTransactionMode set to
NotAnMTSObject for Controller class.

I created a new COM+ Services library application, configured *just* the
Controller class and thought I was away laughing.

To cut a long story short, during my testing I noticed that my

transactions

weren't rolling-back (when I created error conditions). I tried heaps of
things, all the MTSTransactionMode settings on the Implementor class,
switching from Library to Server applications, configured and unconfigured modes, and every time I found that the Implementor class would not run in a

transaction. I verified this by inserting a call to
mObjectContext.IsInTransaction() and raising an error if it returned

False -

which it did - every time.

I sorted it out by also setting the MTSTransactionMode to
RequiresTransaction on the Controller class, and installing *both*
Controller and Implementor in the COM+ Services library application.

Even though the Controller object doesn't use the ObjectContext specifically

(it

never calls GetObjectContext(), SetAbort(), SetComplete() or does any
database work), I guess the transaction is created when the first object
(Controller) is instantiated, and then it's used by the Implementor

object.

I must admit this caught me a bit by surprise. I thought that any

component

could get a reference to it's own ObjectContext regardless of how it's
instantiated. It looks like Implementor will only run in a transaction if the calling component is configured as an MTS object, even if that first
object doesn't need a transaction.

Thanks for reading to the end. I hope I explained things well enough. Does anyone have any thoughts on the behaviour here?

Cheers,

Alan

[Vlad Vissoultchev]

that's what i meant. this way Implementor reference you get will be
intercepted by COM+ and it's transaction settings will be honored. btw, your
Controller will actually get a "fake" proxy :-))

as far as i know WSH couldn't possibly use New because it's nonexistent in
VBScript.

cheers,
</wqw>

"Alan" <SP******************@inspire.net.nz> wrote in message
news:#e**************@TK2MSFTNGP12.phx.gbl...

The Controller object is instantiated using CreateObject in the WSH script, and then instantiates the Implementor object using the New keyword. Should I try changing the Controller class to CreateObject/CreateInstance the
Implementor object?

Thanks for the reply.

Alan

"Vlad Vissoultchev" <wq****@nospam.myrealbox.com> wrote in message
news:er**************@tk2msftngp13.phx.gbl...

do you use CreateObject to create objects?

you can't use New keyword and get the coclass creation interception COM+ is

doing. you have to go CreateObject (or CreateInstance) all the way through

COM libs.

New in VB is using a shortcut to create objects with a simple call to
object's constructor, jumping over all the COM (COM+) interception code.

HTH,
</wqw>
"Alan" <SP******************@inspire.net.nz> wrote in message
news:uk*************@TK2MSFTNGP12.phx.gbl...

Gidday people,

I had a bit of a problem this morning. I think I've got it sorted now, but

I

wonder if anyone can shed some light.

I have a plain VBS WHS file that instantiates a component that controls an interface file import process. This component, Controller, is part of
FinInterface.dll, and instantiates another component, Implementor

(same dll), that does the actual data access (an insert into a

FinanceDataImports

table, and then multiple inserts into a child FinanceData table).

All the data access logic is in the Implementor class so I set the
MTSTransactionMode on this component to RequiresTransaction and did all the

right things with ObjectContext. I left the MTSTransactionMode set to
NotAnMTSObject for Controller class.

I created a new COM+ Services library application, configured *just*

the Controller class and thought I was away laughing.

To cut a long story short, during my testing I noticed that my

transactions

weren't rolling-back (when I created error conditions). I tried heaps of things, all the MTSTransactionMode settings on the Implementor class,
switching from Library to Server applications, configured and

unconfigured modes, and every time I found that the Implementor class would not run in

a

transaction. I verified this by inserting a call to
mObjectContext.IsInTransaction() and raising an error if it returned

False -

which it did - every time.

I sorted it out by also setting the MTSTransactionMode to
RequiresTransaction on the Controller class, and installing *both*
Controller and Implementor in the COM+ Services library application.

Even though the Controller object doesn't use the ObjectContext specifically (it

never calls GetObjectContext(), SetAbort(), SetComplete() or does any
database work), I guess the transaction is created when the first

object (Controller) is instantiated, and then it's used by the Implementor

object.

I must admit this caught me a bit by surprise. I thought that any

component

could get a reference to it's own ObjectContext regardless of how it's
instantiated. It looks like Implementor will only run in a transaction

if the calling component is configured as an MTS object, even if that first object doesn't need a transaction.

Thanks for reading to the end. I hope I explained things well enough. Does anyone have any thoughts on the behaviour here?

Cheers,

Alan