Service object start-up

Question

Hello. We'd like to be able to determine when a TOOL service object
starts up from within another TOOL service object. I understand the
problems with service object start up ordering, but I'll summarize
them here:
1. You can't reference a service object until it's up
2. You can't guarantee a service object to be up unless
a) it's a non-TOOL SO (DB Resource Manager or DB Session)
b) it's a TOOL SO in another partition which is numerically lower
than yours
According to Forte support, we should put our dependant service objects in
different partitions and use the numerical startup to get them going. For
example, if SO A depends on SO B, we need SO B in partition 1 and SO A in
partition 2. Also, if we have A depends on B and nobody else uses B, we
should probably use A as an umbrella for B.
But what if we don't want to do this? What if we don't want to take the
performance hit from the partitioning? What if we've got multiple
client-visible SOs that interact? We tried this scheme:
in A.Init():
super.Init()
start task Startup()
in A.Startup():
while B_SO = NIL do
task.part.operatingsystem.sleep(SPIN_TIME);
end while;
// now do stuff with B_SO
self.Ready = TRUE; // users can test this to see if A_SO is ready
The above works sporadically. According to support, that's because
testing the NIL reference isn't like testing for NIL on a normal object,
the name service is involved and that can screw things up.
Anybody have something that works? This seems to be a really stupid
feature of the system.
========================================================================
Neil Gendzwill, Senior Software Engineer, SED Systems, Saskatoon, Canada
E-MAIL: [email protected] PHONE: [phone] FAX: [phone]
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>

Answer 1

Neil-
The reason your scheme fails occasionally (I'm pretty sure) is the
"start task" in the init method.. The only thing you are guaranteed by
partition order, etc, is that the "init" methods are executed (i.e. the
objects are instantiated) in the order you want. If you start
asynchronous tasks from within the init method, all bets are off as to
whether the spun-off asynchronous task will get done before the next
service object init() is called or even before the first client is
allowed to come on line.. All depends on the thread switching, which of
course cannot be predicted or counted on (hence the term "thread-safe
code").
I use something similar to the subsequent writer on the thread (Mark
Sundsten) except that service objects which need other objects (like
services requiring DB session brokers) go through a multi-step process
waiting for the broker to be up and truly ready for business:
Keep testing for a legal reference to the broker until it is non-NIL
and no exception
Post an "areyoualive" event on the broker with suitable
retry/error-handling until positive response
The broker, of course, does the start task startup() sort of thing in
its init method, the final step of which is to begin responding to
"areyoualive" events with the proper response.
The final trick is that no services on the service object work (they
block/wait) until the object has successfully started (including the
wait for the broker). This is to avoid client requests from being
processed before the service is ready.
With this technique, you can put service objects and their brokers
wherever you want to. I wish it was simpler, but when you enter the
world of multiple threads you need to carefully plan your startup
behavior and bullet-proof all code to be thread safe.
I've also seen techniques where the first actual service request
performs a startup if it hasn't been done already. Sort of the "lazy
instantiation" of service-object startups.. Problem is, of course, that
for the reason outlined above the first client can come alive and begin
asking for things from the services before asynchronous tasks started in
the init methods are done. If you go this direction, make sure you
understand this nuance and have no ansych startups occurring in init
methods.
Hope this helps.
-Greg
-----Original Message-----
From: Neil Gendzwill [SMTP:[email protected]]
Sent: Friday, June 19, 1998 12:48 PM
To: Users, Forte
Subject: Service object start-up
Hello. We'd like to be able to determine when a TOOL service
object
starts up from within another TOOL service object. I understand
the
problems with service object start up ordering, but I'll
summarize
them here:
1. You can't reference a service object until it's up
2. You can't guarantee a service object to be up unless
a) it's a non-TOOL SO (DB Resource Manager or DB Session)
b) it's a TOOL SO in another partition which is numerically
lower
than yours
According to Forte support, we should put our dependant service
objects in
different partitions and use the numerical startup to get them
going. For
example, if SO A depends on SO B, we need SO B in partition 1
and SO A in
partition 2. Also, if we have A depends on B and nobody else
uses B, we
should probably use A as an umbrella for B.
But what if we don't want to do this? What if we don't want to
take the
performance hit from the partitioning? What if we've got
multiple
client-visible SOs that interact? We tried this scheme:
in A.Init():
super.Init()
start task Startup()
in A.Startup():
while B_SO = NIL do
task.part.operatingsystem.sleep(SPIN_TIME);
end while;
// now do stuff with B_SO
self.Ready = TRUE; // users can test this to see if A_SO is
ready
The above works sporadically. According to support, that's
because
testing the NIL reference isn't like testing for NIL on a normal
object,
the name service is involved and that can screw things up.
Anybody have something that works? This seems to be a really
stupid
feature of the system.
========================================================================
Neil Gendzwill, Senior Software Engineer, SED Systems,
Saskatoon, Canada
E-MAIL: [email protected] PHONE: [phone] FAX: (306)
933-1486
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive
<URL:http://pinehurst.sageit.com/listarchive/>
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>