How exactly does Err.Raise behave in a class hosted in COM+?

[entaroadun]

In a VB app using an in-process DLL, Err.Raise seems pretty straightforward. The Err.Raise line creates an error that propagates up the call stack to find a space with error handling enabled. To be truly safe, a class using Err.Raise to communicate errors should release all references to objects before calling Err.Raise.

Is this correct?

How about in COM+? If I have a VB Standard EXE front end instantiating business components in COM+, what happens to the COM component if I execute Err.Raise there? Is it the same? Should I call SetAbort and release all references before calling Err.Raise? Assuming error handling only in the UI EXE, does Err.Raise cause the business object code to terminate and pass execution to the UI?

Basically, I'm trying to understand how error throwing / handling in multithreaded apps work. I'm new to this, and I'm trying to wrap my mind around it.

I guess in an app with an in-process DLL, which runs multithreaded but in a single apartment, the OS makes sure that all code runs linearly, simulating a single thread but taking advantage of multithreaded processing.

How does it work with an out-of-process server? I guess the in-process DLL is loaded into mtx.exe, which makes it out-of-process with respect to the client exe. But the client.exe and mtx.exe threads run in a single apartment, causing linear processing? So the client can call a method on a COM component instance, and the client will wait until the method returns, even though they run on separate threads?

Am I on track?

I'm so confused.

Basically, if I use Err.Raise in a public method of a COM+ component, should I clean up first by calling SetAbort and releasing all references?

Does anyone know of good books or articles that explain this fully? I'm looking for excruciating detail so I can understand exactly what happens.

 

[SemperFiDownUnda]

If your application is writen with stateless objects then normal practice is to call SetAbort and raise the error to the caller (unless you can programming wise fix the error). SetAbort will clean up the object once the original caller is finished. So basically chain SetAbort & err.raise err.number... all the way back to the client if you don't handle errors programatically in your objects.
Your client app then can do what ever. Since your object are stateless it can retry (maybe the error was a connection error to an SQL server because it crashed) give the server enough time to reboot and try agian and the transaction should go through.

Personally I don't release references but let the SetAbort handle the clean up....bad of me I know but hey they would have fallen out of scope in 1 more line of code anyway.

Hope this helps