Article ID: 169210
Article Last Modified on 3/3/2005
APPLIES TO
- Microsoft Transaction Services 1.0
- Microsoft COM+ 2.0 Standard Edition
This article was previously published under Q169210
SUMMARY
This article presents a list of do's and don'ts when creating COM objects to be used by Microsoft Transaction Server that utilize database technology.
MORE INFORMATION
The following list is general across development environments used to create the COM objects, with product specific notes as applicable.
- Don't put anything in the C++ constructor / destructor. The Object Context is not available during object construction and it is impossible to signal errors from a constructor or destructor. Implement IObjectControl/ObjectControl and use the Activate/Deactivate methods to do initialization.
- Do create your COM object as an in-process server, preferably with dual interface.
- Don't turn connection pooling off.
- Don't use an open database cursor within the COM object that persists between client method calls into the object. When the client invokes a method in the object and the method opens a recordset, the recordset should be closed before the method returns.
- Do beware of cursors. Opening them in transactions can have locking implications. Handing them to clients can have further implications. Use them cautiously and use some of the new technologies like ADO/RDO batch cursors.
- Do use forward-only, read-only recordsets within the COM Object. If you need to update the data, use SQL syntax (INSERT, UPDATE).
- Since method calls are across DCOM, do everything you can to reduce the number of network round trips. Keep your methods large. This typically means method calls with lots of parameters that perform multiple tasks on the server.
- Don't keep any state information. MTS may destroy and re-create your component at any time. State can also have severe scalability implications. If you want to store state or share it across objects use the Shared Property Manager
- Do pass arguments ByValue whernever possible, this helps minimize network trips. Marshalling object references can be expensive.
- Do Minimize actual Resource Manager transaction duration. Long transactions can cause concurrency issues in the database. Note that although MTS creates a DTC transaction upon object creation, this transaction has no real penalty until work is performed by the RM.
- Do acquire resources as late a possible and release them as soon as possible. Others probably want them too.
- Don't implement resource pooling yourself. Use the MTS programming model. It might be tempting to implement something to gain a little performance or add a feature now, but there is no guarantee that it will not be broken in the future. Grow with MTS.
- Keep resource allocation generic so that it can be pooled. ODBC connections are a good example. It is tempting to open connections as the calling user for easy auditing in the database, but those connections cannot be reused except by that user. This can be a performance hit. This can be worked around by using ISecurityProperty to get SIDs/user names and sending to the database as needed.
- Do place security at the door (roles on interfaces and components) and audit the rest of the way as needed.
Keywords: kbinfo KB169210
