[VSRV][V4RB] connection status

Tim Davis timdavis at amug.org
Wed Sep 3 13:23:27 CDT 2003


Hi Ruslan and Igor,

>> Here are a couple other ideas (not necessarily as a replacement for
>> server IsOpen) that would be even faster. You may not like them, I'm
>> just thinking of speed.
>>
>> 1. The server "tells" the client it is disconnected (or will be), and
>> the client retains the boolean property, or reconnects immediately.
>
> GOOD IDEA.
>
> Although, This can work only if client still alive.
> But if client go to coffee, and line is good, server really will be 
> able do
> this.

I'm thinking the server attempts a message connection to the client, if 
successful tells client "disconnecting" (the databases). In which case 
the client app can choose to store the status of the db connection or 
reconnect. If the server contacting the client fails, it simply doesn't 
worry about it (as the client app may have crashed or the computer 
unexpectedly went off network, etc).

>> 2. The server simply "reconnects" on new requests after timeout. (Then
>> of course what might be the advantage of timing out? ... )
>
> Not clear.

What I'm saying is the server could be set to never fail due to a 
disconnect. Which is not much different from setting the server to not 
timeout (unless there is some other reason/advantage to breaking the 
connection periodically).

>> The disadvantage of IsOpen is the client needs to ask every time prior
>> to a database activity. But it is better than the action failing due 
>> to
>> timeout. The second idea above avoids this repetitive line of code and
>> requests to the server.
>
> Igor say that RIGHT NOW, if you do some operation, and it fails you get
> exception in languages where they exists or db.err otherwise.
>
> So yes, this is the most effective way.
> Although Igor say in current version READ can hang on long time...
> We will think how to make this in the best way

I'm trying to avoid looping around (action, error, reconnecting and 
trying action again) due to a disconnect error. If that is the best 
way, I will have to live with it, but I think these other possibilities 
might make our coding easier and quicker.

To recap, you've mentioned the following new possibilities:
	Server timeout of "0" (no timeout)
	Extending server timeout minutes (at least 12 hrs preferred)
	Server boolean property of db.IsOpen (testing connection status)
	Server messages client app with "db.IsClosing" (boolean)
I'll be curious to know if any of these will be added.

Thanks,
Tim Davis



More information about the Valentina mailing list