Problem:
Customer uses ServerExpress's cobjrun to start IBM WebSphere 5.1.
Customer wrapped a COBOL application with Java. The Java Wrapper is called by EJBs in an J2EE application running on IBM WebSphere 5.1.
In a typical J2EE application running on WebSphere, the memory usage increases during daytime (peak) and decreases during night time (off-peak) due to Java's garbage collection.
However, customer noticed that after running with cobjrun the memory usage increases during daytime, but stays the same during the night, and the next day it increases again.
Resolution:
This way of working it is not the way we recommend. When a java EJB needs to call COBOL, the recommended way of working is to run your COBOL program under Enterprise Server as a service and use the Interface Mapping Toolkit and the Resource Adapters technology to communicate the java EJB with the COBOL Service.
We don't think that these memory problems have anything to do with using cobjrun. There shouldn't be any difference between using the java trigger or the cobjrun trigger. Once "cobjrun" creates the JVM, finds the requested class and invokes the "main" method it never returns. So it is very doubtful that the issue is due to just using the cobjrun trigger.
COBOL programs used within the above environment could cause memory to increase unexpectedly. For example if the COBOL program was executed within a "Thread Pool". The memory allocated/associated with the thread will never be released until the thread terminates but in a thread pool environment this never occurs, so the memory is never released.
Also, your COBOL program is wrapped within a class under the covers, but COBOL doesn't have any garbage collector.
This is not specific of the java environment, these are limitations that COBOL has within other third party threading environments, it is not a limitation of our java support.
These are just some of the reasons why we recommend to use the J2EE connector that we provide with Enterprise Server. Also, using a COBOL service external to the J2EE is the architecture that Sun recommends to connect to other languages (not just COBOL).
