On Thu, 18 Apr 2002 17:10:03 +0100, Alan Williams <[EMAIL PROTECTED]> wrote: >Could you try to clarify something for me, Peter. > >I will create a New() object. >I will then call Init() on that object to set some properties. Init() >will DisableCommit to keep the object active after the Init() returns >(Done bit = false).
The done bit is false by default. The transaction vote however is Commit by default. DisableCommit keeps the done bit false, but also marks the transaction vote as Abort. Which I would guess is a more logical state in your Init case. The default state (of Done=false, Tx=Commit) is the equivalent of having called EnableCommit. >I will then call a transactional method that uses the connection string >property. >This method will write to the database and then SetComplete() or >SetAbort() to commit or abort the transaction. This will set the Done >bit = true ... and the object will deactivate(?) Yes, after SetComplete or SetAbort the done bit is true and the object will deactivate when returning from the method call. You can see this happen if you implement IObjectControl and do something interesting in the IObjectControl::Deactivate method (such as writing to debug output). >Can I then call another method (possibly the same method) on the object >without having to instantiate and initialise it again? I am thinking of >something like ... Yes and no. Your object reference is still valid. When you use it, it will cause a new object (or possibly even the one just deactivated if the object is pooled) to be activated (again you can see this happen by looking at IObjectControl::Activate). But, the object will have no state left from before its deactivation - so you must reinitialize it. It is like having a whole new fresh object. Which is different to the normal COM and OO idiom. I have heard it explained like this: The reasoning is that since it is a transactional component, and the transaction has commited, any state it did have is possibly not correct and should be obliterated. (Personally I'm not entirely convinced by this explaination.) Think of the object and the reference to the object as two different entities entirely. Your object reference remains valid, but the object it refers to comes and goes, being set up (activated) and torn down (deactivated) at transactional boundaries. >Dim objMyObject as New TransactionalObject() >objMyObject.Init(x,y,z) >For c = 1 TO n > objMyObject.TransactionalMethod(.. , .. , ..) >Next You probably need to move your Init inside the loop, since any state set up in Init is gone after the first transaction commits and the object deactivates. Hope this helps, Peter Foreman You can read messages from the DOTNET archive, unsubscribe from DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
