(I'm sure I screwed something up in the example above; it's been a good long while since I've used C++.)
Making that wrapper object looks like the only way I can see to do what you want - and I think it's probably smarter.
Though the double pointer works, if this service can indeed die at *any* time, that makes the system a little fragile. What happens if the service dies mid-user method? Is your service object prepared to handle that? What about threading - isn't there a
race condition in replacing the pointer?
Actually, shouldn't you be able to do the service replacement within the service object? Why do you need to replace the actual instance? Can't you just do some finagleing about with internal state?
Good questions, lemme throw in some more background.
I'm working on a WinForms user control, and the "server" object is a 3rd party wrapper for a WebService object. At some point, the server may timeout, and any further calls on the same server object will fail.
As for race conditions, that is a danger, but I'm combatting that by wrapping calls to the server object in locks on the server object itself. I'm only ever making one call to the server at a time (typically to get a bit of binary data), and I don't have to
send any updates to the server, so I don't have to worry about inconsistent state.
It's outside the realm of my control to replace the server object. I *may* be able to repair the object, but if the server requires a new login, I don't have the user's password. So it would be good if I simply responsibly reported a failure and let the application
handle the cleanup.
Yesterday, I implemented a simple wrapper object for the server object to share it as necessary. I think this is the solution I'll stick with.
Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation, please create a new thread in our Forums, or Contact Us and let us know.