Issue 1628: POA API support for default servant (port-rtf) Source: (, ) Nature: Revision Severity: Summary: Summary: The current POA APIs do not adequately support the use of default servants in the POA. The particular operations of concern are servant_to_id, servant_to_reference, and id_to_servant. Resolution: Revised Text: Actions taken: July 2, 1998: received issue July 30, 1998: closed issue Discussion: Revision: Section 9.3.8 "POA Interface". End of Annotations:===== bReturn-Path: Sender: "George Scott" Date: Wed, 01 Jul 1998 22:16:26 -0700 From: "George M. Scott" Organization: Inprise Corporation To: port-rtf@omg.org CC: issues@omg.org, java-rtf@omg.org Subject: POA API support for default servant The current POA APIs do not adequately support the use of default servants in the POA. The particular operations of concern are servant_to_id, servant_to_reference, and id_to_servant. First, let's discuss id_to_servant first. For some reason, id_to_servant does not have the ability to return the default servant, although reference_to_servant does. This appears to be an oversight in the spec, more than an intential design decision since one can call reference_to_id, and then call id_to_servant. So, the first proposal is to modify id_to_servant so that it behaves like reference_to_servant with respect to the default servant. I would hope we could agree on this with out much debate. The next two are servant_to_reference and servant_to_id. These two methods require the RETAIN policy and appear by design to be only used with the Active Object Map. However, there is a problem here for the Java language mapping and the use of _this(). In the Java language mapping there is a portability layer we must provide so that we can have binary interoperability between vendors. Because of this we have defined _this() to invoke servant_to_reference(). So, for the Java language mapping to support _this() in default servants (as is used in all of the C++ default servant examples in Chapter 9) we need to either change the behavior of servant_to_reference or add a get_reference method to POACurrent, or both. I think at this point changing the API of POACurrent may be difficult since POA implementations are already beginning to appear. So my preference is to change the behavior of servant_to_id and servant_to_reference. servant_to_id will essentially be the same as calling POACurrent::get_object_id if the specified servant is the default servant. servant_to_reference will essentially create a reference using the object id with no type information (the equivalent of caling POA::create_reference(POACurrent::get_object_id(), ""). Below is our proposed resolution: --------------------------------------------------- Issue XXXX: POA API support for default servant Nature: revision Summary: The current POA APIs do not adequately support the use of default servants in the POA. The particular operations of concern are servant_to_id, servant_to_reference, and id_to_servant. Resolution: Accepted for Corba 2.3 RTF Revision: Change the text as follows: Replace the entire text in the id_to_servant description on page 9-37, Section 9.3.8 with the following: "This operation requires the RETAIN policy or the USE_DEFAULT_SERVANT policy. If neither policy is present, the WrongPolicy exception is raised. If the POA has the RETAIN policy and the specified ObjectId is in the Active Object Map, this operation returns the servant associated with that object in the Active Object Map. Otherwise, if the POA has the USE_DEFAULT_SERVANT policy and a default servant has been registered with the POA, this operation returns the default servant. Otherwise the ObjectNotActive exception is raised." Replace the first paragraph of the servant_to_id description on page 9-36, section 9.3.8 with the following: "This operation requires the USE_DEFAULT_SERVANT policy or the RETAIN policy and either the UNIQUE_ID or IMPLICIT_ACTIVATION policies; if not present, the WrongPolicy exception is raised." Add the following bullet item after the second bullet in the servant_to_id description and change the text from "three possible behaviors" to "four possible behaviors": " * If the POA has the USE_DEFAULT_SERVANT policy, the servant specified is the default servant, and the operation is being invoked in the context of execuing a request on the default servant, then the ObjectId associated with the current invocation is returned." Replace the first paragraph of the servant_to_reference description on page 9-36, section 9.3.8 with the following: "This operation requires the USE_DEFAULT_SERVANT policy or the RETAIN policy and either the UNIQUE_ID or IMPLICIT_ACTIVATION policies; if not present, the WrongPolicy exception is raised." Add the following bullet item after the second bullet in the servant_to_reference description and change the text from "three possible behaviors" to "four possible behaviors": " * If the POA has the USE_DEFAULT_SERVANT policy, the servant specified is the default servant, and the operation is being invoked in the context of execuing a request on the default servant, then the the reference associated with the current invocation is returned (the returned reference may not contain any type information because correct type information may not be known to the POA)." ----------------------------------------- George Return-Path: Date: Thu, 02 Jul 1998 12:22:24 -0400 From: Jonathan Biggar Organization: Floorboard Software To: "George M. Scott" CC: port-rtf@omg.org, issues@omg.org, java-rtf@omg.org Subject: Re: POA API support for default servant References: <359B17AA.7D3A030@inprise.com> Here are my comments on this proposal: George M. Scott wrote: > The current POA APIs do not adequately support the use of > default servants in the POA. The particular operations of > concern are servant_to_id, servant_to_reference, and > id_to_servant. > > First, let's discuss id_to_servant first. For some reason, > id_to_servant does not have the ability to return the > default servant, although reference_to_servant does. This > appears to be an oversight in the spec, more than an intential > design decision since one can call reference_to_id, and then > call id_to_servant. So, the first proposal is to modify > id_to_servant so that it behaves like reference_to_servant > with respect to the default servant. I would hope we could > agree on this with out much debate. I noticed this too, and convinced myself that the behavior was different on purpose.By having id_to_servant() fail if the id is not in the active object map, this allows the program to determine whether the object associated with the id is activated or not. If this is modified to return the default servant, then it is harder to find this out. > The next two are servant_to_reference and servant_to_id. > These two methods require the RETAIN policy and appear by > design to be only used with the Active Object Map. However, > there is a problem here for the Java language mapping and > the use of _this(). In the Java language mapping there is > a portability layer we must provide so that we can have binary > interoperability between vendors. Because of this we have > defined _this() to invoke servant_to_reference(). So, for > the Java language mapping to support _this() in default servants > (as is used in all of the C++ default servant examples in > Chapter 9) we need to either change the behavior of > servant_to_reference or add a get_reference method to > POACurrent, or both. > > I think at this point changing the API of POACurrent may be > difficult since POA implementations are already beginning to > appear. So my preference is to change the behavior of > servant_to_id and servant_to_reference. servant_to_id will > essentially be the same as calling POACurrent::get_object_id > if the specified servant is the default servant. > servant_to_reference will essentially create a reference > using the object id with no type information (the equivalent > of caling POA::create_reference(POACurrent::get_object_id(), ""). Can I suggest a simplification to your proposal? How about simply stating that if servant_to_id() or servant_to_reference() are called in the context of an invocation with the servant that was invoked, then servant_to_id returns the same result as PortableServer::Current::get_object_id()? It seems that referring to the default servant here is redundant. > Below is our proposed resolution: > > --------------------------------------------------- > Issue XXXX: POA API support for default servant > Nature: revision > > Summary: The current POA APIs do not adequately support the use > of default servants in the POA. The particular > operations of concern are servant_to_id, > servant_to_reference, and id_to_servant. > > Resolution: Accepted for Corba 2.3 RTF > > Revision: Change the text as follows: > > Replace the entire text in the id_to_servant description on > page 9-37, Section 9.3.8 with the following: > > "This operation requires the RETAIN policy or the USE_DEFAULT_SERVANT > policy. If neither policy is present, the WrongPolicy exception is > raised. > > If the POA has the RETAIN policy and the specified ObjectId is in the > Active Object Map, this operation returns the servant associated with > that object in the Active Object Map. Otherwise, if the POA has the > USE_DEFAULT_SERVANT policy and a default servant has been registered > with the POA, this operation returns the default servant. Otherwise > the ObjectNotActive exception is raised." > > Replace the first paragraph of the servant_to_id description on > page 9-36, section 9.3.8 with the following: > > "This operation requires the USE_DEFAULT_SERVANT policy or the > RETAIN policy and either the UNIQUE_ID or IMPLICIT_ACTIVATION > policies; if not present, the WrongPolicy exception is raised." > > Add the following bullet item after the second bullet in the > servant_to_id description and change the text from "three possible > behaviors" to "four possible behaviors": > > " * If the POA has the USE_DEFAULT_SERVANT policy, the servant > specified is the default servant, and the operation is being invoked > in the context of execuing a request on the default servant, then > the ObjectId associated with the current invocation is returned." > > Replace the first paragraph of the servant_to_reference description on > page 9-36, section 9.3.8 with the following: > > "This operation requires the USE_DEFAULT_SERVANT policy or the > RETAIN policy and either the UNIQUE_ID or IMPLICIT_ACTIVATION > policies; if not present, the WrongPolicy exception is raised." > > Add the following bullet item after the second bullet in the > servant_to_reference description and change the text from "three possible > behaviors" to "four possible behaviors": > > " * If the POA has the USE_DEFAULT_SERVANT policy, the servant > specified is the default servant, and the operation is being invoked > in the context of execuing a request on the default servant, then > the the reference associated with the current invocation is returned (the > returned reference may not contain any type information because correct type > information may not be known to the POA)." Type information would only be unknown to the POA if the servant is a dynamic servant. Can't the POA just call the dynamic servant's _primary_interface() function (or its equivalent in other language mappings) at this point to get the type information? -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Return-Path: Date: Mon, 06 Jul 1998 11:50:02 -0400 From: Paul H Kyzivat Organization: NobleNet To: Jonathan Biggar CC: "George M. Scott" , port-rtf@omg.org, issues@omg.org, java-rtf@omg.org Subject: Re: POA API support for default servant References: <359B17AA.7D3A030@inprise.com> <359BB3BF.B6D6B975@floorboard.com> Jonathan Biggar wrote: > > Here are my comments on this proposal: > > George M. Scott wrote: > > > The current POA APIs do not adequately support the use of > > default servants in the POA. The particular operations of > > concern are servant_to_id, servant_to_reference, and > > id_to_servant. > > > > First, let's discuss id_to_servant first. For some reason, > > id_to_servant does not have the ability to return the > > default servant, although reference_to_servant does. This > > appears to be an oversight in the spec, more than an intential > > design decision since one can call reference_to_id, and then > > call id_to_servant. So, the first proposal is to modify > > id_to_servant so that it behaves like reference_to_servant > > with respect to the default servant. I would hope we could > > agree on this with out much debate. > > I noticed this too, and convinced myself that the behavior was > different on > purpose.By having id_to_servant() fail if the id is not in the > active > object > map, this allows the program to determine whether the object > associated with the > id is activated or not. If this is modified to return the default > servant, then > it is harder to find this out. I too believe that this looks like a mistake in the original writeup that should be corrected. Sorting out whether a servant was received because it was active or the default isn't especially difficult, nor is it a distinction that will very often need to be made. Consistency is preferable here. > > > The next two are servant_to_reference and servant_to_id. > > These two methods require the RETAIN policy and appear by > > design to be only used with the Active Object Map. However, > > there is a problem here for the Java language mapping and > > the use of _this(). In the Java language mapping there is > > a portability layer we must provide so that we can have binary > > interoperability between vendors. Because of this we have > > defined _this() to invoke servant_to_reference(). So, for > > the Java language mapping to support _this() in default servants > > (as is used in all of the C++ default servant examples in > > Chapter 9) we need to either change the behavior of > > servant_to_reference or add a get_reference method to > > POACurrent, or both. > > > > I think at this point changing the API of POACurrent may be > > difficult since POA implementations are already beginning to > > appear. So my preference is to change the behavior of > > servant_to_id and servant_to_reference. servant_to_id will > > essentially be the same as calling POACurrent::get_object_id > > if the specified servant is the default servant. > > servant_to_reference will essentially create a reference > > using the object id with no type information (the equivalent > > of caling POA::create_reference(POACurrent::get_object_id(), ""). > > Can I suggest a simplification to your proposal? How about simply > stating that > if servant_to_id() or servant_to_reference() are called in the > context > of an > invocation with the servant that was invoked, then servant_to_id > returns the > same result as PortableServer::Current::get_object_id()? It seems > that > referring to the default servant here is redundant. This sounds fine. It solves the problem and makes the rules simpler at the same time. I do have one question of interpretation regarding "called in the context of an invocation", both here and anywhere that determination is needed: If the calling thread has more than one invocation context active (e.g. because of nested co-located invocations), do we consider only the top invocation on the stack, or any/all invocations on the stack? For instance, in this case I would much prefer that only the most recently activated invocation context be required to be checked for a matching servant. Doing this for other activations is as likely to do the wrong thing as the right thing. Return-Path: Sender: "Jon Goldberg" Date: Mon, 06 Jul 1998 16:36:16 -0700 From: Jon Goldberg To: Jonathan Biggar CC: gscott@inprise.com, java-rtf@omg.org, port-rtf@omg.org Subject: Re: POA API support for default servant References: <359B17AA.7D3A030@inprise.com> Jonathan Biggar wrote: > > Here are my comments on this proposal: > > George M. Scott wrote: > > > The current POA APIs do not adequately support the use of > > default servants in the POA. The particular operations of > > concern are servant_to_id, servant_to_reference, and > > id_to_servant. > > > > First, let's discuss id_to_servant first. For some reason, > > id_to_servant does not have the ability to return the > > default servant, although reference_to_servant does. This > > appears to be an oversight in the spec, more than an intential > > design decision since one can call reference_to_id, and then > > call id_to_servant. So, the first proposal is to modify > > id_to_servant so that it behaves like reference_to_servant > > with respect to the default servant. I would hope we could > > agree on this with out much debate. > > I noticed this too, and convinced myself that the behavior was > different on > purpose.By having id_to_servant() fail if the id is not in the > active object > map, this allows the program to determine whether the object > associated with the > id is activated or not. If this is modified to return the default > servant, then > it is harder to find this out. We don't feel very strongly about this one, but would like to make sure everything is as consistent as possible. On the surface, it is not apparent why id_to_servant is different from the others. If this really was intentional, we should add a statement to the description of the operation to avoid this coming up again. Can anyone confirm or deny Jon B.'s conclusion that id_to_servant's behavior really is different by design? > > Below is our proposed resolution: > > > > --------------------------------------------------- > > Issue XXXX: POA API support for default servant > > Nature: revision > > > > Summary: The current POA APIs do not adequately support the use > > of default servants in the POA. The particular > > operations of concern are servant_to_id, > > servant_to_reference, and id_to_servant. > > > > Resolution: Accepted for Corba 2.3 RTF > > > > Revision: Change the text as follows: > > > > Replace the entire text in the id_to_servant description on > > page 9-37, Section 9.3.8 with the following: > > > > "This operation requires the RETAIN policy or the > USE_DEFAULT_SERVANT > > policy. If neither policy is present, the WrongPolicy exception is > > raised. > > > > If the POA has the RETAIN policy and the specified ObjectId is in > the > > Active Object Map, this operation returns the servant associated > with > > that object in the Active Object Map. Otherwise, if the POA has > the > > USE_DEFAULT_SERVANT policy and a default servant has been > registered > > with the POA, this operation returns the default servant. > Otherwise > > the ObjectNotActive exception is raised." > > > > Replace the first paragraph of the servant_to_id description on > > page 9-36, section 9.3.8 with the following: > > > > "This operation requires the USE_DEFAULT_SERVANT policy or the > > RETAIN policy and either the UNIQUE_ID or IMPLICIT_ACTIVATION > > policies; if not present, the WrongPolicy exception is raised." > > > > Add the following bullet item after the second bullet in the > > servant_to_id description and change the text from "three possible > > behaviors" to "four possible behaviors": > > > > " * If the POA has the USE_DEFAULT_SERVANT policy, the servant > > specified is the default servant, and the operation is being > invoked > > in the context of execuing a request on the default servant, then > > the ObjectId associated with the current invocation is returned." > > > > Replace the first paragraph of the servant_to_reference > description on > > page 9-36, section 9.3.8 with the following: > > > > "This operation requires the USE_DEFAULT_SERVANT policy or the > > RETAIN policy and either the UNIQUE_ID or IMPLICIT_ACTIVATION > > policies; if not present, the WrongPolicy exception is raised." > > > > Add the following bullet item after the second bullet in the > > servant_to_reference description and change the text from "three > possible > > behaviors" to "four possible behaviors": > > > > " * If the POA has the USE_DEFAULT_SERVANT policy, the servant > > specified is the default servant, and the operation is being > invoked > > in the context of execuing a request on the default servant, then > > the the reference associated with the current invocation is > returned (the > > returned reference may not contain any type information because > correct type > > information may not be known to the POA)." > > Type information would only be unknown to the POA if the servant is > a dynamic > servant. Can't the POA just call the dynamic servant's > _primary_interface() > function (or its equivalent in other language mappings) at this > point to get the > type information? > I don't think there really is a problem regarding a lack of type information. As a proxy-George, I propose changing that last bullet item by removing the parenthetical note. It becomes: * If the POA has the USE_DEFAULT_SERVANT policy, the servant specified is the default servant, and the operation is being invoked in the context of executing a request on the default servant, then the the reference associated with the current invocation is returned. take care, Jon Return-Path: Sender: jon@floorboard.com Date: Tue, 07 Jul 1998 20:00:38 -0700 From: Jonathan Biggar To: Paul H Kyzivat CC: "George M. Scott" , port-rtf@omg.org, issues@omg.org, java-rtf@omg.org Subject: Re: POA API support for default servant References: <359B17AA.7D3A030@inprise.com> <359BB3BF.B6D6B975@floorboard.com> <35A0F22A.BD890DEE@noblenet.com> Paul H Kyzivat wrote: > I do have one question of interpretation regarding "called in the > context of an invocation", both here and anywhere that determination > is > needed: > > If the calling thread has more than one invocation context active > (e.g. > because of nested co-located invocations), do we consider only the > top > invocation on the stack, or any/all invocations on the stack? > > For instance, in this case I would much prefer that only the most > recently activated invocation context be required to be checked for > a > matching servant. Doing this for other activations is as likely to > do > the wrong thing as the right thing. Certainly the most recently activated invocation is the only one that should apply. Anything else would violate the principal of least suprise. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Return-Path: Date: Mon, 20 Jul 1998 13:16:25 -0400 From: Paul H Kyzivat Organization: NobleNet To: "George M. Scott" CC: port-rtf@omg.org Subject: Re: urgent POA issues References: <35AC23DC.7B2F1ECF@inprise.com> <35AD332B.F8D71F57@noblenet.com> <35AD8ABE.D8982CAB@inprise.com> George M. Scott wrote: > Paul H Kyzivat wrote: > > > OK, I think I see your problem. The spec implied to me (although it > > isn't explicit) that the serialization of incarnate and etherealize > must > > extent to stalling a subsequent incarnation while an etherealization > is > > pending for the same objectId. > > > > This is different than requiring the object to remain active until > the > > etherealization begins - tests for the presence of the object can > still > > fail (because it has been deactivated) and an explict activation is > OK. > > No, because a user can also call activate_object and not use incarnate > and this will result in two copies of an object being created. True. And in this example that would be a bad thing. It would also not be something that would normally be done in this case. The POA model provides many different ways of doing things, using different combinations and subsets of the available features. At the same time, each different way of doing things can be broken by using some features. Other than the couple of elementary articles Steve has written in the C++ report, I have not seen anything like a set of use-cases describing the different usage possibilities that are intended. (Please correct me if I am wrong on this - I would love to be pointed to a set of use-cases that the POA design is intended to support.) In the absence of these we each have some use cases in our own minds that we are trying to make work. In the use-case of your example, explicit activation should not be used. I am sure I can come up with another case where it would be safe and useful. > > It indeed might be the case that id_to_servant would fail. This has > > nothing to do with the timing of etherealization - it only has to do > > with explicit multithreading code written by the developer. Why > should > > it succeed? It is unwise to be be writing code that depends on > > activations in a POA while at the same time writing concurrent code > that > > removes them. And this isn't a hard thing to avoid in this case > since > > the servant ought to already know who it is, or it can find out from > > POACurrent. > > Several members of the OMG are currently working on a proposal for > CORBA components. As part of this proposal users will write > components > (servants) which implement some business logic or other functions. > These components will be deployed in a container (POA + extra code) > which will activate/deactivate objects as necessary. So the user > will actually have little control over the concurrency of calls > executing while an object is being deactivated because they > are not writing the entire server, only a single servant which is > running inside of a sophisticated component server. It is not safe > to assume that a single person wrote all code which runs inside of > a server process. This is a good argument. But there will clearly need to be a number of assumptions/rules about how the POA features are used (and not used) to realize this capability. It may be entirely reasonable to ban use of id_to_servant in this environment. > > > Now if it isn't clear already, the POA destroy operation has the > exact > > > same > > > problem. If the server were to manage objects by destroying > entire > > > POAs > > > instead of individual objects then it is possible to have a POA > B > and > > > a POA > > > B' in existence at the same time. And not only have a single > object > > > inconsistent but an entire set of objects managed by that POA > totally > > > inconsistent. I'm sure that will sell a lot of POA > > > implementations.... > > > > The analogy isn't perfect. In the case of POAs, the only thing > that > is > > ever explicitly visible is a reference to a POA - there are no > visible > > POA servants (though they may exist in a particular ORB > implementation.) > > > > Just as a regular object reference remains invariant though it may > map > > to different servants from time to time, a reference to a POA > should > > also remain invariant though it may refer to a different > incarnation > of > > that POA from time to time. So it should never appear as if there > is > > both a B and a B'. > > I'm confused by your statement. Are you saying that a reference to > a > POA that is destroyed and then is later recreated is still a valid > reference? I don't think this is the case. And if it is the case, > then > this should be very explicitly stated in the spec. For example: Am am at least saying that this is a valid interpretation of the spec. I think I can also make a good argument that it is the best interpretation of the spec. I am not under the illusion that it is the only possible interpretation. It may or may not be one of those things that should be left undefined. Hopefully some discussion here will lead to a conclusion one way or the other. Here is my reasoning: 1) The POA is not a pseudo-object; it is a full fledged but locally constrained object. 2) Object references created in a POA implicitly refer to that POA. If the POA has the PERSISTENT policy and is destroyed and recreated, objects created in the earlier generation are still valid for the second generation of POA. 3) If the POA has the TRANSIENT policy and is destroyed and recreated, then objects created in the earlier generation are invalid for the second generation of POA. 4) In case (2), when the behavior of a POA itself is compared to that of a regular object, it acts more like a persistent object than a transient object. If I destroy it and then invoke one of the references it had previously created it may well come back to life. If so, makes sense to me that the reference to the POA itself should also remain valid 5) There is less of an argument for a POA with the TRANSIENT policy. Here I think it is acceptable either to have the reference to the POA remain the same or change as long as the behavior of the contained references is handled correctly. > > Imagine the rootPOA is available and has an adapter activator > installed > which can create a POA named "foo". Executing the following code > will > activate the POA, then destroy it. > > // Java > POA a = rootPOA.find_POA("foo", true); > a.destroy(false, false); > > Now are you stating that if I now invoke an operation on "a", that > it > will recreate the POA? For example: > > a.the_name(); > > will actually reactivate the POA? Or will it throw > OBJECT_NOT_EXIST. > It was my understanding that a destroyed POA will always throw > OBJECT_NOT_EXIST when invoked, and recreating the same POA will not > result in the old reference suddenly becoming valid again. I think it should throw OBJECT_NOT_EXIST until such time as it is recreated (explicitly or implicitly via an AdapterActivator). If and when it is recreated, then the original reference could become once again valid. Having use of the reference to the POA call the AdapterActivator is more of a step than I had considered. Return-Path: Date: Tue, 21 Jul 1998 19:52:17 -0400 From: Paul H Kyzivat Organization: NobleNet To: Jonathan Biggar CC: "George M. Scott" , port-rtf@omg.org Subject: Re: urgent POA issues References: <35AC23DC.7B2F1ECF@inprise.com> <35AD332B.F8D71F57@noblenet.com> <35AD8ABE.D8982CAB@inprise.com> <35B37B69.40E27797@noblenet.com> <35B383C4.5F4C812D@floorboard.com> <35B3D353.7970258A@noblenet.com> <35B3DA9A.D632324A@floorboard.com> Jonathan Biggar wrote: > > Paul H Kyzivat wrote: > > If it looks like a duck, and walks like a duck, and quacks like a > duck, > > what is it? > > But it doesn't. :-) The operation is called "destroy", not > "deactivate". In this case, "destroy" is just a 7 byte identifier. It is not inherited from any standard interface that specifies any particular semantics, so the only meaning that we should ascribe to it is in the description of this particular operation in the POA spec. The description of this operation sounds no more permanent to me than the description of deactivate_object does. > > > The POA doesn't derive from Lifecycle, so the semantics of its > 'destroy' > > operation are whatever it choses them to be. There are already > words > to > > the effect that if a poa is created with the same name after > destruction > > of a prior one, or in a subsequent instantiation of the server, > that > it > > must have the same policies. And, when a servant manager is > present, > it > > is expected to handle references to inactive objects from prior > > instantiations of the POA. This certainly sounds to me like the > object > > was dead and has been brought back to life. Under the > circumstances, > I > > think it should just be able to have its old social security > number > back > > :) > > Granted that the new POA is much like the old one, if not almost > exactly > identical, but I just don't see the practicality of allowing the POA > reference to resurect itself. I don't find it to be impractical. > > Think about it a bit. What can the application do if using a POA > reference raises OBJECT_NOT_EXIST? There is no signal that it can > wait > on until the POA reference works again. So the simplest thing to do > is > to throw away the old reference and call find_POA again to get a new > reference that should work. There just isn't any good reason to > allow > POA references to be resurrected when there is a simple application > action to correct the problem. What you suggest is always an option for the user. As long as the user acts this way it makes no difference whether the new POA reference is the same as the old one or not. The greatest benefit of this is to the orb implementation itself. References to colocated objects can refer to their POA directly rather than having to look it up for every reference. Because references of this kind have to continue to work as the POA is destroyed and recreated, this is one way to save a bunch of bookkeeping. Suppose you are declared dead and your ss# is closed, and then are later discovered not to be dead. Things would be much simpler for you and all those you deal with if your ss# was reinstated than if you were assigned a new one. This is the same thing. This is the way regular object references work, and it is a useful feature.