OK to call activate_object?

OK to call activate_object?

Post by Michael McKnerne » Fri, 11 Jul 2003 02:55:24



Hi,

Is it safe to call activate_object() while ServantActivator::incarnate()
is executing?   (of course, it's from within a class that implements the
ServantActivator interface).  Same POA or different POA matter?

Here's our scenario in  pseudo code ...

// idl
interface A {};
interface B {};

// implementation
Servant class AImpl holds an instance of servant class BImpl.

Both AImpl and BImpl are subject to re-activation via use of a
ServantActivator.

We keep a list of ObjectIds for active AImpl's and periodically
deactivate AImpl's  by calling deactivate_object on the oids.  When an
AImpl destructs, it calls deactivate_object() on the BImpl that it
contains.

Works fine.

Now, say that a client invokes on a BImpl that is not yet activated, so
the ServantActivator::incarnate() is called and we keep knowledge in the
ObjectId to know to create a new BImpl, however, we also need to create
a new AImpl to contain the new BImpl (so that the reaping strategy stays
intact) and we also need to activate the AImpl at this time. So the
question is to whether or not it's okay to call activate_object on AImpl
at this time?

Hopefully I stated the scenario in an understandable way :-)

Are there better approaches to use while still using a
ServantActivator?  I know using a DefaultServant or ServantLocator is
probably better but was wondering about better ideas using a
ServantActivator.

Thanks allot,
Mike

 
 
 

OK to call activate_object?

Post by Michi Hennin » Fri, 11 Jul 2003 20:39:39



> Now, say that a client invokes on a BImpl that is not yet activated, so
> the ServantActivator::incarnate() is called and we keep knowledge in the
> ObjectId to know to create a new BImpl, however, we also need to create
> a new AImpl to contain the new BImpl (so that the reaping strategy stays
> intact) and we also need to activate the AImpl at this time. So the
> question is to whether or not it's okay to call activate_object on AImpl
> at this time?

Yes, that's OK. The POA guarantees that it won't concurrently call
incarnate() or etherealize(), and that it mutually interlocks
incarnate() and etherealize(). So, if you instantiate another servant
as part of incarnate() and add it to the AOM with activate_object(),
that's no problem.

Quote:> Are there better approaches to use while still using a
> ServantActivator?  I know using a DefaultServant or ServantLocator is
> probably better but was wondering about better ideas using a
> ServantActivator.

None that I'm aware of. In general, the logic of things tends to be
more understandable with servant locators, and they also allow you
build nifty things such as evictors. (See Steve's and my book for
more details:
http://www.aw-bc.com/catalog/academic/product/0,4096,0201379279,00.html

Cheers,

Michi.

--
Michi Henning                Ph: +61 4 1118-2700
ZeroC, Inc.                  http://www.zeroc.com

 
 
 

OK to call activate_object?

Post by Michael McKnerne » Sat, 12 Jul 2003 03:02:04




> > Now, say that a client invokes on a BImpl that is not yet activated, so
> > the ServantActivator::incarnate() is called and we keep knowledge in the
> > ObjectId to know to create a new BImpl, however, we also need to create
> > a new AImpl to contain the new BImpl (so that the reaping strategy stays
> > intact) and we also need to activate the AImpl at this time. So the
> > question is to whether or not it's okay to call activate_object on AImpl
> > at this time?

> Yes, that's OK. The POA guarantees that it won't concurrently call
> incarnate() or etherealize(),

For the same ObjectId, right?

Quote:> and that it mutually interlocks
> incarnate() and etherealize().

What do you mean by 'interlocks'?

Quote:> So, if you instantiate another servant
> as part of incarnate() and add it to the AOM with activate_object(),
> that's no problem.

> > Are there better approaches to use while still using a
> > ServantActivator?  I know using a DefaultServant or ServantLocator is
> > probably better but was wondering about better ideas using a
> > ServantActivator.

> None that I'm aware of. In general, the logic of things tends to be
> more understandable with servant locators, and they also allow you
> build nifty things such as evictors. (See Steve's and my book for
> more details:
> http://www.aw-bc.com/catalog/academic/product/0,4096,0201379279,00.html

Speaking of your (great) book, I had a question for you about the behavior of
_non_existent().  Has the spec changed since your book was written because I
was told that this operation *will* always contact the sever (under Orbix 2000
at least).  And how could any ORB perform this method without contacting the
server?

Quote:

> Cheers,

> Michi.

> --
> Michi Henning                Ph: +61 4 1118-2700
> ZeroC, Inc.                 http://www.zeroc.com

thanks for your help!

mike

 
 
 

OK to call activate_object?

Post by Michi Hennin » Sat, 12 Jul 2003 07:44:55




> > Yes, that's OK. The POA guarantees that it won't concurrently call
> > incarnate() or etherealize(),

> For the same ObjectId, right?

Nope. Here is what the spec says:

        - Servants incarnated by the servant manager will be placed in the
          Active Object Map with objects they have activated.

        - Invocations of incarnate on the servant manager are serialized.

        - Invocations of etherealize on the servant manager are serialized.

        - Invocations of incarnate and etherealize on the servant manager are
          mutually exclusive.

        - Incarnations of a particular object may not overlap; that is,
          incarnate shall not be invoked with a particular ObjectId
          while, within the same POA, that ObjectId is in use as the
          ObjectId of an activated object or as the argument of a call
          to incarnate or etherealize that has not completed.

It says that "invocations of incarnate on the servant manager are
serialized." To me, this says that no two calls to incarnate() can occur
concurrently, whether for the same ObjectId or different Object Ids.
The last point says that incarnate() won't be called on something that
is already activated; teh second part of the para is really redundant,
given what is said in the first three bullet points.

Quote:> > and that it mutually interlocks
> > incarnate() and etherealize().

> What do you mean by 'interlocks'?

If a call to incarnate() is currently in progress, no call to
etherealize() will be in progress (whether for the same ObjectId or
a different ObjectId).

Quote:> Speaking of your (great) book, I had a question for you about the behavior of
> _non_existent().  Has the spec changed since your book was written because I
> was told that this operation *will* always contact the sever (under Orbix 2000
> at least).  And how could any ORB perform this method without contacting the
> server?

No, _non_existent() need not always contact the server. In particular,
it can return true without going remote. The object model guarantees
that, once _non_existent() has returned true, it always returns true.
So, the client-side run time could cache the true return value and
return true if _non_existent() is called on the same reference a second
time without contacting the server.

Cheers,

Michi.

--
Michi Henning                Ph: +61 4 1118-2700
ZeroC, Inc.                  http://www.zeroc.com

 
 
 

OK to call activate_object?

Post by Michael McKnerne » Wed, 23 Jul 2003 07:56:43





> > > Yes, that's OK. The POA guarantees that it won't concurrently call
> > > incarnate() or etherealize(),

> > For the same ObjectId, right?

> Nope. Here is what the spec says:

There is some key text from the spec that you missed just before what you state
below and it states:

    "When the POA has the RETAIN policy it uses servant managers that are
ServantActivators. When using such servant managers, the following statements apply
for a given ObjectId used in the incarnate and etherealize operations:"

I think the "given ObjectId" part is significant.  But if what you say is correct,
then I'll file a bug report for Orbix 2000 because I'm seeing that calls on
incarnate() are allowed to execute simultaneously when the oid is different.

(btw- I actually took this quote from the 2.4 spec so maybe this para has changed
since)

Thanks for helping me get this clarification/behavior straightened out.

Mike

Quote:

>         - Servants incarnated by the servant manager will be placed in the
>           Active Object Map with objects they have activated.

>         - Invocations of incarnate on the servant manager are serialized.

>         - Invocations of etherealize on the servant manager are serialized.

>         - Invocations of incarnate and etherealize on the servant manager are
>           mutually exclusive.

>         - Incarnations of a particular object may not overlap; that is,
>           incarnate shall not be invoked with a particular ObjectId
>           while, within the same POA, that ObjectId is in use as the
>           ObjectId of an activated object or as the argument of a call
>           to incarnate or etherealize that has not completed.

> It says that "invocations of incarnate on the servant manager are
> serialized." To me, this says that no two calls to incarnate() can occur
> concurrently, whether for the same ObjectId or different Object Ids.
> The last point says that incarnate() won't be called on something that
> is already activated; teh second part of the para is really redundant,
> given what is said in the first three bullet points.

> > > and that it mutually interlocks
> > > incarnate() and etherealize().

> > What do you mean by 'interlocks'?

> If a call to incarnate() is currently in progress, no call to
> etherealize() will be in progress (whether for the same ObjectId or
> a different ObjectId).

> > Speaking of your (great) book, I had a question for you about the behavior of
> > _non_existent().  Has the spec changed since your book was written because I
> > was told that this operation *will* always contact the sever (under Orbix 2000
> > at least).  And how could any ORB perform this method without contacting the
> > server?

> No, _non_existent() need not always contact the server. In particular,
> it can return true without going remote. The object model guarantees
> that, once _non_existent() has returned true, it always returns true.
> So, the client-side run time could cache the true return value and
> return true if _non_existent() is called on the same reference a second
> time without contacting the server.

> Cheers,

> Michi.

> --
> Michi Henning                Ph: +61 4 1118-2700
> ZeroC, Inc.                 http://www.zeroc.com

 
 
 

OK to call activate_object?

Post by Michi Hennin » Wed, 23 Jul 2003 22:05:26




> > Nope. Here is what the spec says:

> There is some key text from the spec that you missed just before what you
state
> below and it states:

>     "When the POA has the RETAIN policy it uses servant managers that are
> ServantActivators. When using such servant managers, the following statements
apply
> for a given ObjectId used in the incarnate and etherealize operations:"

Right, I missed that.

Quote:> I think the "given ObjectId" part is significant.

I think so too -- my interpretation too is that serialization applies only for
the same
Object ID. (I should have known from memory but, I admit, I rarely use
servant activators. Servant locators are the more general concept and can
be used to do the same job. And, with servant locators, I take care of my
own locking anyway, so there is nothing I have to rely on in the ORB run time.)

Quote:> But if what you say is correct,
> then I'll file a bug report for Orbix 2000 because I'm seeing that calls on
> incarnate() are allowed to execute simultaneously when the oid is different.

No, I think that is permissible according to the spec.

Quote:> (btw- I actually took this quote from the 2.4 spec so maybe this para has
changed
> since)

I checked agains the latest (3.0.2) and it's still the same.

Cheers,

Michi.