Tie mechanism the context of Visibroker

Tie mechanism the context of Visibroker

Post by vin.. » Fri, 06 Feb 1998 04:00:00



Are there any disadvantages of using the Tie mechanism with Visibroker ?

Problems with efficiency, deletion of objects when unbound/aborted,
multithreading constraints, event handling at the server side .. ?
Any special cases where Tie mechanism is necessary ?

Thanks in advance,
Vinay

 
 
 

Tie mechanism the context of Visibroker

Post by John Lace » Fri, 06 Feb 1998 04:00:00



> Are there any disadvantages of using the Tie mechanism with Visibroker ?

> Problems with efficiency, deletion of objects when unbound/aborted,
> multithreading constraints, event handling at the server side .. ?
> Any special cases where Tie mechanism is necessary ?

It's a little messier to create and clean up objects with the tie
classes. I'm still not convinced I've gotten the reference
counting correct to properly release the real object and the tie
object at the same, and correct, time.

Supposedly they are useful to encapsulate an interface already
fixed before the CORBA interface was defined, but I find it hard
to believe that would work for more than one in a thousand cases,
when the interface matched closely enough to work. In other
words, I don't know what the tie classes are for.

They are, however, necessary on Windows NT, due apparently to a
bug in Visual C++ regarding exceptions in constructors of classes
with virtual bases. This is how VisiBroker and Orbix implement
the server skeleton, so you may find it hard, impossible, or poor
coding practice to use the usual "inherit from the skeleton"
approach. So you use tie classes.

At least, I suppose that could happen. ;-)

John L



 
 
 

Tie mechanism the context of Visibroker

Post by John Lace » Tue, 10 Feb 1998 04:00:00



> Does that mean that Tie objects have a different reference count & the
> object encapsulated has a different reference count ? I thought only
> objects derived from CORBA::object have reference counts ..

You are correct, although of course nothing prevents you from
having reference counts on your own objects, independent of the
tie class or CORBA::Object.

No, the difficulty is in arranging for the two objects to go away
at the same and appropriate time, preferrably without editing the
tie class definition. You could simply delete the embedded
object, but you should call release on the tie object, and you
need to ensure that if you delete the embedded object then
release will delete the tie object. Otherwise you will have a
valid server object (the tie object) with an dangling reference
to a destroyed embedded object. The opposite situation (a valid
implementation object but no server object) is at best a memory
leak, and potentially just as bad as a dangling reference.

I don't know. I will have to think about this some day.

Quote:> > They are, however, necessary on Windows NT, due apparently to a
> > bug in Visual C++ regarding exceptions in constructors of classes
> > with virtual bases.

> Hey, what is this bug  ?

Afaik, you can't throw an exception from a constructor of a class
with a virtual base class. I'm not sure if it's required that the
base class have an explicit destructor.

John L


 
 
 

1. Tie mechanism

I have a question/problem to use tie mechanism to wrap my legacy class

My legacy class are:

//------------------
Classe LegacyClassA
//------------------
Public:
 SetX(double x);
 SetY(double y);
...}

//------------------
Classe LegacyClassB
//------------------
{
Public:
 Boolean ConvertTo(double radius, LegacyClassA& coord );
...}

radius value that must be converted
coord object that is to receive the converted value

These are legacy application, so they must not be updated.

Now, I need to write the IDL

interface IDLB
 {
 void SetX(Double x);
 void setY(Double y);
 };

interface IDLA
 {
 boolean ConvertTo(in Double rad, out IDLB coor);
 };

Part of the incarnation servant is:
...
1) LegacyClassA tied_object = new LegacyClassA();
2) POA_IDLA_tie<LegacyClassA> tie_servant(tied_object);
3) IDLA_var my_objectA = tie_servantA._this();

4) LegacyClassB tied_object = new LegacyClassB();
5) POA_IDLB_tie<LegacyClassB> tie_servant(tied_object);
6) IDLB_var my_objectB = tie_servantB._this();

7) PortableServer::ObjectId_var managerIdA =
PortableServer::string_to_ObjectId("Coord");
8) PortableServer::ObjectId_var managerIdB =
PortableServer::string_to_ObjectId("Radian");
9) // Activate the servant with the ID on myPOA
10) myPOA->activate_object_with_id(managerIdA, &tie_servantA);
11) myPOA->activate_object_with_id(managerIdB, &tie_servantB);
...

There is a compil time error with line 5:
ConvertTo(double radius, LegacyClassA& coord ) const' : cannot convert
parameter 2 from 'class IDLA_out' to 'class LegacyClassA &'

The client should be something like this:

    PortableServer::ObjectId_var managerIdA =
PortableServer::string_to_ObjectId("Coord");
    IDLA_var mng_coord = IDLA::_bind("/Test_poa", managerIdA);
    PortableServer::ObjectId_var managerIdB =
PortableServer::string_to_ObjectId("Radian");
    IDLB_var mng_radian = IDLB::_bind("/Test_poa", managerIdB);

Then, I could write
    CORBA::Boolean flag = mng_radian->ConvertTo(3.14,mng_coord);

Should I write some implementation code to transform IDLA_out to
LegacyClassA & ?
How will you do this ?

I begin with corba, maybe is there something I misanderstood (sur...)
and now I don't know more if the tie delegation is the good solution.
Not look so simple to wrap legacy class...

Thanks for your help. Eric.
Sorry, it's very long.

2. comp.dcom.sys.cisco Frequently Asked Questions (FAQ)

3. tie mechanism

4. Strange problem

5. Visibroker TIE question

6. Postscript manual

7. Visibroker 4.0 call back mechanism

8. DVD & CD-RW & Zip 250

9. tie or no_tie: What about tie and no_tie ?

10. Visibroker/C++ and Request Contexts ?

11. Visibroker 3.0 Context Objects

12. Using Context in Visibroker for Java

13. Visibroker/CORBA Context