[omniORB] Re: distinguishing remote and local objects

[Chung, David]

	Thank you for your reply.

----------

	I am trying to have a transaction server work in distributed
environment (but not necessarily compliant with CORBA Transaction Services
specificaiton).  The reason for distinguishing remote and local objects is
as follows.

	A local transactional server is capable of making calls to (1) to
another local transactional server or (2) a remote transactional server.
(transactional server = servers that are capable of participating in a
transaction).

	If the call is local, the second server (invoked server) can simply
register itself with the locally allocated data structure known as
transaction control block (which was already allocated when the local
transaction began) and participate in the transaction.  If the call is
remote, the remote transaction system must first allocate a new control
block for keeping track of remote transaction (colocated with the invoked
server).  The invoked server can then register itself with the new
transaction control block.  As you can see, remote server calls go through
different execution steps.
	
	You might ask, why can't the remote server simply register itself
with the original transaction control block, instead of registering itself
with newly allocated, remote control block?  Wouldn't life be simpler that
way?  The reason is because of problems associated with distributed
recovery: (1) distributed recovery would be very slow; (2) the recovery of
one system would depend too much on remote servers and the network.  A
systems whose recovery is coordinated through a single process (or a single
thread) would not be able recover unless remote servers (which were
participants in earlier transasctions and which are now down) also recovered
successfully and is able to successfully transmit recovery information to
dependent systems.

	By having a remote server register with a colocated transaction
control block, the preceding problems can be dealt with.  (1) the recovery
is much faster and (2) recovery of one system does not fully depend on
recovery of remote systems or the network, even for the type of system whose
recovery is coordinated via a single process.

----------

	I will be grateful for any comments.



> -----Original Message-----
> From:	gnuish@uswest.net [SMTP:gnuish@uswest.net]
> Sent:	Monday, October 04, 1999 10:35 PM
> To:	David.Chung@USPTO.GOV
> Subject:	Re: [omniORB] Re: distinguishing remote and local objects
> 
> I am currious what you need to do differently locally as opposed to
> remote.
> Pleasee elaborate and I might be able to suggest a more mainstream
> solution.
> 
> --rob
> 
> ----- Original Message -----
> From: Chung, David <David.Chung@USPTO.GOV>
> To: <omniorb-list@uk.research.att.com>
> Sent: Thursday, September 30, 1999 3:17 PM
> Subject: [omniORB] Re: distinguishing remote and local objects
> 
> 
> > Dear omniORB developers and users:
> >
> > Does anyone know if there exists an interface or a function call
> > (supported by omniORB) that I can make on a CORBA Object (reference) to
> test
> > if it is in the same address space as the caller or not?
> >
> > I understand that the point of using CORBA is to obtain location
> > transparency; that is, it makes remote objects look local.  But my
> > application need to handle remote and local calls differently -- hence,
> I
> > need to somehow probe CORBA object to extract the information.
> >
> > Another approach to solving this problem is to use classes that are
> > CORBA wrappers; that is, I can use class objects which simply contains
> both
> > CORBA reference and a flag (to indicate whether it is remote or local).
> > However, this is not the preferred approach as it incurs overhead.
> >
> > I will be grateful for any comments.
> >
> > (sorry about essentially duplicating this e-mail -- my earlier
> > writing was not too clear).
> >
> >