[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference varese::basestar_open

Title:BASEstar Open Multiplatform Application Framework
Notice:Kit pointers: see topic 3
Moderator:VARESE::CORBETTA
Created:Tue Oct 02 1990
Last Modified:Fri Jun 06 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:607
Total number of notes:1971

605.0. "BSTR Client Connectivity" by MSAM03::JANARDHAN () Mon Jun 02 1997 11:09

    hello zocolla,
    
    	Thanks for your reply. Could you please explain how does the client
    keep track of the connectivity with the server. Suppose if the BSTR
    realm to which it is connected is shutdown, unset, reset it back
    and started with all the objects recreated, how does the DDE bridge
    establish its connectivity with the realm.
    
    Anticipating your reply!
    
    Thanks and regards
    JANA.K.
T.RTitleUserPersonal
Name
DateLines
605.1Some explanationsVARESE::ZOCCOLADeprimitElatosLevatAlexandriaStratosMon Jun 02 1997 11:3449
Jana,

I am not an expert recovery-API user, however I can explain you its basic 
functionality.

When you create a B* API application, to address B* objects you must create
handles to these objects ( "references" in B* terms); starting from version 3.0
of B* Client (not yet available for Server library), when you create the 
references for the objects, you can use a flag to tell B* that those references
are very important to you, so that in case of connection failure B* must a
automatically recreate them for you.

(Look at the API manual, "bstr_reference_set()" function, BSTR_C_RECOVERY_REQ
flag).


Another step to instruct B* to recover the references is the use of the
"bstr_reference_recover()" API call.

After "bstr_initialize()" you must call "bstr_reference_recover()" once, to tell
B* what user callback it must invoke during the possible recovery phase.
In practice, once you have specified the callback you want to be used, the
callback will be invoked many times during the recovery phase:

- When the recovery process starts
- If the recovery process retries many times the reference rebuild, every time
  the callback will be invoked
- When the recovery ends with success
- When the recovery ends with failure

Every time you must return BSTR_S_NORMAL or some error condition, according to
your needs.
The two parameters in the "bstr_reference_recover" ("new_callback" and
"old_callback") are needed only if you want to change the recovery callback
over time.

(Look at the API manual, "bstr_reference_recover()" function)



	Hope this helps.




			< Aldo >