Article ID: 296994
Article Last Modified on 12/5/2007
APPLIES TO
- Microsoft COM+ 1.0
- Microsoft COM+ 1.5
- Microsoft Visual J++ 6.0 Standard Edition
- Microsoft Java Virtual Machine
This article was previously published under Q296994
IMPORTANT: This article contains information about modifying the registry. Before you modify the registry, make sure to back it up and make sure that you understand how to restore the registry if a problem occurs. For information about how to back up, restore, and edit the registry, click the following article number to view the article in the Microsoft Knowledge Base:
256986 Description of the Microsoft Windows Registry
SYMPTOMS
If an application that is written in Visual J++ involves Component Object Model (COM) components, the application may exhibit the following problems when you host it in COM+:
- Excessive memory usage
- Exhaustion of available memory
- Excessive context switching
- CPU affinity
The same application may perform acceptably under Microsoft Transaction Server (MTS) but displays these symptoms when you upgrade the application to COM+.
RESOLUTION
Follow these guidelines when you develop and deploy Java COM components in a COM+ environment:
- Use the appropriate COM+ hotfix.
- Use the latest version of the Microsoft virtual machine for Java.
- Mark all your components as Apartment threaded.
- Disable special handling of objects that aggregate the FTM.
- Call declareMessagePumpThread.
- Wherever possible, make use of ComLib.release in your application.
- If your application involves Windows Foundation Classes for Java (WFC) and ActiveX Data Objects (ADO), try to use ADO directly.
For more information about each of these guidelines, refer to the "More Information" section.
NOTE: Although these guidelines have helped in many applications, because every application is different, these guidelines may not optimize the performance of all applications. The most important objective is to thoroughly test your complete application for integration and load with the "designed for" capacity before you deploy it.
MORE INFORMATION
For Java COM components to perform optimally in the COM+ environment, follow these guidelines.
Use the Appropriate COM+ Hotfix
Because several issues have become apparent since the release of Microsoft Windows 2000 and Microsoft Windows XP that affect COM+, it is recommended that you install Windows 2000 Service Pack 2 (SP2) or later. However, several hotfixes have released since Windows 2000 SP2 for COM+ that address specific issues. Some of these issues either directly or indirectly affect Java COM components. It is recommended that you obtain COM+ Rollup Hotfix 14 or later. For additional information, click the article number below to view the article in the Microsoft Knowledge Base:
302845 INFO: Availability of Windows 2000 Post-Service Pack 2 COM+ Hotfix Rollup Package 14
If you are using COM+ 1.5 (in Windows XP), you do not need to apply these hotfixes.
Use the Latest Version of the Microsoft Virtual Machine for Java
Ensure that you are using Microsoft virtual machine for Java (Microsoft VM) build 3802 or later. Msjava.dll builds prior to build 3802 have a number of problems that could affect the performance and scalability of Java components that run in COM+. In addition, builds 3802 and later include all of the latest security fixes. To determine which Microsoft VM build number is installed on your computer, examine the last four digits of the full version number.
Mark All Your Components as Apartment Threaded
Mark all your components as Apartment threaded before you import them into COM+. By default, components that Visual J++ creates register themselves as Both threaded. When you register these components in COM+, they are instantiated on multithreaded apartment (MTA) threads when they are created from external clients. Because the Microsoft VM performs all garbage collection of such components on a single background thread (the Server Apartment Thread), a bottleneck can occur in the application.
In addition, if your application uses Apartment threaded COM components (for example, ADO is marked as Apartment by default), more cross-thread marshaling can occur than when you run the application under Microsoft Transaction Server.
To mark all the components as Apartment threaded, use one of the following methods:
- To do this manually, modify the ThreadingModel registry value for all CLSIDs, and then import the components into COM+. Do not use a drag-and-drop operation to move the components because COM+ re-registers the dynamic-link libraries (DLLs), and the threading model reverts to Both.
- Implement the onCOMRegister method in your components, and explicitly write Apartment to the ThreadingModel key. This is the preferred method.
- Use a build process that uses Jexegen.exe to generate the DLL. You can use command-line switches on this tool to specify the threading model. For more information about this method, refer to the Microsoft Software Development Kit (SDK) for Java 4.0.
Disable Special Handling of Objects That Aggregate the FTM
WARNING: If you use Registry Editor incorrectly, you may cause serious problems that may require you to reinstall your operating system. Microsoft cannot guarantee that you can solve problems that result from using Registry Editor incorrectly. Use Registry Editor at your own risk.
If you use any components that aggregate the Free Threaded Marshaler (FTM) (such as ADO and Microsoft XML), follow these steps:
- Start Registry Editor (Regedt32.exe).
- Locate and click the following key in the registry:
HKEY_LOCAL_MACHINE\Software\Microsoft\Java VM
- On the Edit menu, click Add Value, and then add the following registry value:
Value name: FTMChecksDisabled
Data type: REG_DWORD
Value data: 1 - Quit Registry Editor.
This registry setting prevents the Microsoft VM from checking whether the COM objects that it creates aggregate the FTM. Without this value, the garbage collection of such objects occurs from the Server Apartment Thread. This can lead to a rapid increase in memory usage.
Call declareMessagePumpThread
Assuming that all of your components are now marked as Apartment threaded, you must ensure that you call the com.ms.com.ComLib.declareMessagePumpThread method at least once on every thread that uses Java. Because you have no direct control over which thread from the COM+ STA thread pool you execute on, you can only ensure this by always calling this method in any function that is an entry point from external clients into a COM+ package. If you call this method multiple times, you do not alter the end result. Because calling this method involves little overhead, it is easier to call the method again than to track whether you already called it.
NOTE: Do not call this method on an MTA thread; the results cannot be predicted.
If your component does not call declareMessagePumpThread in COM+, any Apartment threaded objects that you create are instantiated on a different single threaded apartment (STA) thread and garbage collected on the Server Apartment Thread. This leads to excessive context switching and overloads the Server Apartment Thread.
Wherever Possible, Make Use of ComLib.release in Your Application
Wherever possible, make use of ComLib.release in your application to release references to COM objects explicitly when you are finished with them. This helps to relieve some of the pressure on the garbage collection mechanism.
If Your Application Involves WFC/ADO, Try to Use ADO Directly
If your application uses the ADO classes in the Windows Foundation Classes for Java (WFC), consider using ADO directly instead. This gives you greater control of when the underlying ADO COM objects are released.
REFERENCES
For additional information on specific Java and COM+ problems, click the article numbers below to view the articles in the Microsoft Knowledge Base:
275610 FIX: Memory Leaks in Java/COM When You Use Variant or SafeArray Parameters
282834 FIX: Error When You Apply COM+ Role-Based Security to Java COM Interfaces
301377 COM+ Application That Uses Visual J++ Components May Deadlock
260353 FIX: Use of Java/COM Components in COM+ Enabled Systems Can Cause Delays
232368 PRB: Java Threads Blocking when Accessing COM Objects
290513 BUG: COM+ Error 80070057 'Error in .\jit.cpp(512'
289615 Java Components Invoked from JScript May Generate Error Message
For additional information about the performance of Java COM applications, click the article number below to view the article in the Microsoft Knowledge Base:
281201 INFO: Performance Issues with the Microsoft Virtual Machine
You can obtain the latest version of the Microsoft VM from the following Microsoft Web site
You can obtain Windows 2000 Service Pack 2 from the following Microsoft Web site:
For support information about Visual J++ and the SDK for Java, visit the following Microsoft Web site:
Additional query words: MSXML hang deadlock leak growth transaction server upgrade slow ComLib.release() onCOMRegister() Java COM poor performance
Keywords: kbprb KB296994
