Issue 1964:  Creating TypeCodes safely in java (java-rtf)
Source:  (, )
Nature:  Uncategorized Issue
Severity: 
Summary: Summary: There are problems with creating recursive TypeCodes containing values.Our proposal is really quite simple.  We want to add a new class to the
 org.omg.CORBA.portable package defined as follows:
 
 package org.omg.CORBA.portable;
 
 final public class TypeCodeLock {
 }
 
 All generated type() methods in Helper"s could synchronize on the
 TypeCodeLock"s class object to grab a global lock which is used during
 TypeCode creation to guarnatee the atomicity of TypeCode creation.
 Note, this is essentialy what is done in C++ where TypeCodes are typically
 initialized in a global static initalizer which is done from a single
 thread.  We are just allowing the typecodes to be created lazily.
 

Resolution: Close, no action
Revised Text: 
Actions taken:
September 16, 1998: received issue
June 4, 1999: closed issue
Discussion: 

End of Annotations:=====
Return-Path: <gscott@inprise.com>
Sender: "George Scott" <gscott@inprise.com>
Date: Wed, 16 Sep 1998 13:08:00 -0700
From: "George M. Scott" <gscott@inprise.com>
Organization: Inprise Corporation
To: java-rtf@omg.org
Subject: Creating TypeCodes safely in Java.

There are problems with creating recursive TypeCodes containing
values.
We have a proposed solution for solving this problem:

Our design requirements are as follows:

1. TypeCodes should be lazily created when a user calls the type()
method,
   and should not necessarily be created in advance, because the
TypeCode
   may not be needed, and would simply waste system resources.

2. Mutliple threads should be able to call any Helper's type() method 
   and get TypeCodes which are complete.  There should be no potential
   for deadlock, or any other thread-related problems.

3. The TypeCodes produced should minimize memory usage.  As a general
rule
   we would like to have only one TypeCode instance in memory for any
   given IDL type, regardless of the order in which those TypeCodes
were
   constructed.

4. Performance for getting an already created TypeCode should be fast,
but
   it is allowable to have TypeCode creation to have some cost.

5. We are assuming the new API propsed by Jon Biggar for creating 
   recursive TypeCodes based on a repository id.

Our proposal is really quite simple.  We want to add a new class to
the
org.omg.CORBA.portable package defined as follows:

package org.omg.CORBA.portable;

final public class TypeCodeLock {
}

All generated type() methods in Helper's could synchronize on the
TypeCodeLock's class object to grab a global lock which is used during
TypeCode creation to guarnatee the atomicity of TypeCode creation.
Note, this is essentialy what is done in C++ where TypeCodes are
typically
initialized in a global static initalizer which is done from a single
thread.  We are just allowing the typecodes to be created lazily.

For example:

public class AHelper {

  privage org.omg.CORBA.TypeCode _type = null;

  org.omg.CORBA.TypeCode type() {
    if (_type == null) {
      synchronized(org.omg.CORBA.portable.TypeCodeLock.class) {
        if (_type == null) {
          // create the TypeCode (left as an exercise to the reader
;-) )
          ...
        }
      }
    }
    return _type;
  }
}

This meets all of our requirements.

1. TypeCodes can be created lazily.
2. Using a global lock prevents deadlock, assuming all helper classes
   are using the same lock.
3. Although not shown, this does meet this requirement assuming Jon
   Biggar's new TypeCode API for recursive typecodes.
4. Getting a TypeCode is very fast requiring only an if statement.  
   Creating a TypeCode requires locking a global monitor, plus the
   ORB overhead of actually creating the TypeCode.

George