Sorry, Gents, I raised this question initially, I think all I have heard here is that there is no answer, not sure you have thought about how hard to track that by using a global variable.
I appreciate your comments (really, it's been helpful), but I found it's hard to turn it into a good practice, not only for this issue, also those have passed, forgive my honesty.
Here comes my thought on the similar issue. An alternative should be provided if you think there is something missed from the view of design, it then can be shared by all your customers, the solution for converting codes using the alternative way to the codes using added feature should be provided as soon as the new feature becomes available, it'll make the transition for all the customers much more easier, otherwise each of us has to pay extra effort to do this on our own, it may screw up all the mature codes if we do it in a way which is not being tested at all. does it make sense?
For this issue, I would rather hold till I get the feature release, could any of you give an estimated time frame?
Thank all of you!
Zhenqui
Can you describe the use case where you need to check existence of a session before executing steps on that session? I would assume that you can achieve the same by overriding the global event for your testcase or testbed to achieve the same effect as your "if session is closed then execute the following steps".
Have you thought about passing the "sesion name" into the called procedure? And then just verify that the session has "opened" before you make this call.
This is probably better than writing a procedure that has lots of extra logic to determine whether or not the session it is using is open. The exception being if the procedure's job is to "reopen" the session.
As an ugly work around, you could override the OnSessionNotOpen event in the procedure and then do whatever you were going to do when the session isn't open.
It's not particularly helpful now, I know, but in a future release, something that would facilitate something like this is the addition of waits and signals. If you're opening a session in a remote procedure in some thread, you can have threads that will use that session wait until they get the signal that the session has opened, and the session can send out this signal once it's open to allow those other threads to move forward once it's open. Similarly, you can have the session wait to close until it's been signaled by all of the threads that are using it. This should help eliminate some of the race conditions that you get with session opening/closings.
An alternative workaround now is to do something similar to what Wei described, but you could use a while loop to wait while the variable doesn't exist (if you want to poll on the availability of that session). That way, if it doesn't exist yet, but it will open eventually, you won't skip those steps that you could have run. Obviously, if your session might have closed, you may need to be extra careful, because then you'll just run forever. In that case, you may want a variable that has three states: unopened, opened, and closed: while it's unopened, you can poll on its availability and sleep for a couple of seconds every time it's not. If it opens, proceed forward. If it's already been closed, it would probably be best to skip all your steps :).
No one has followed this question yet.