[bug report 2040] Vserver, NOTE 2. HOW TO write client/server apps

[Charles Yeomans]

On Dec 13, 2006, at 4:39 AM, Ivan Smahin wrote:

> Hello Ruslan,
>
> Wednesday, December 13, 2006, 11:09:36 AM, you wrote:
>
>> On 12/06/12 8:37 PM, "Charles Yeomans" <charles at declareSub.com>  
>> wrote:
>
>>>> 1) Agree this is quite natural from OO point of view design
>>>>
>>>>     object1.open
>>>>             object2.open()
>>>>
>>>>             object2.close()
>>>>     object1.close
>>>>
>>>> Looking on this abstract notation, anybody will expect that
>>>> object2, which
>>>> is LOWER by hierarchy will close object1? Of course not!
>>>>
>>>> Does this clean explanation?
>>>
>>>  From an OO point of design as presented in, say, Stroustrup's  
>>> "The C+
>>> + Programming Language", I would expect that the VConnection
>>> destructor would close the connection.
>
>> AGREE. So the same must do code as
>
>>>>     object1.open
>>>>             object2.open()
>>>>
>>>>             object2.close()
>>        object1 = nil
>
>> Ivan, I believe this works in our case, right ?
>
> Yes. Destructor of connection close self before destroying.

It appears to do so in the simplest test.  But this code

   dim c as new VConnection("localhost", "sa", "sa")
   c.Open
   dim db as new VDatabase(c)
   db.Open new FolderItem("testdb")
   db.Close

still eats up connections.  My report of this was closed with the  
comment "THIS IS correct behavior!".  But I fail to see how it can  
be.  All databases using this connection are closed.  Yet when the  
connection object is destroyed, the connection is not closed.

>
>>> Here is the way I think the interaction should work.
>>>
>>> Create VConnection object.
>>>
>>> Calling VConnection.Open should be possible, but optional.
>
>> NO.
>
>> This is VERY REQUIRED step in the current model/technology.
>> This cannot be changed.
>
>>> VDatabase.Constructor(connection as VConnection) should behave as  
>>> you
>>> describe above.  Right now, V4Rb registers a "null" database with  
>>> the
>>> server.
>
>> No, it will not behave in this way.
>>
>
> Actually it could be changed but not much.
> I  mean  we can check the connection state in database constructor and
> if  it  is  not  opened  -  open  it.  But right - we can not make the
> database without opened connection, i.e. let connection open in  
> some point
> after db object is created is impossible.
>
> So there is not much to get from such changes - the only thing you  
> will
> get is "Connection.Open call is optional".

What we users get is an API that is easier to use reliably.  If we  
wanted to suffer, we would use C++ :)

>
>
>>> VDatabase.Open should call VConnection.Open; testing suggests that
>>> VConnection.Open is a no-op if the connection object has already  
>>> been
>>> opened.
>
>> NO, again, we cannot do this.
>
>> Because we need already opened connection when we start construct  
>> database
>> object. This process ALREADY communicate with server.
>>
>
> Exactly.
>
>>> VConnection.Close should call VDatabase.Close for every database
>>> using that connection.
>
>> In fact when you CLOSE connection, then on server side all right,
>> On client side - all db/cursor objects that you have create in  
>> scope of this
>> connection become INVALID. You should not touch them.
>
>> So virtually YES, connection.close -> kill all its objects.
>>
>
> Just  "close connection"  means for server:  "Immediately free  
> everything which is
> used  in  this  connection". After this step we have no proxies in the
> server for this connection anymore.
> Even if you open that connection again - you have a different set
> of proxies in the server. Trying  to  use "virtually killed" client- 
> objects
> like database, table and so on will lead to exception on the server.
>
> So Connection.Open/Close behave like Init/Shutdown operations.
>
> 1.  You  are  not  able  to  create healthy valentina's object without
>     making connection open before.
>
> 2.  You  will  get error using any Valentina's object after  
> connection is closed.
>
> 3. You can not do:
>    Connection.Open
>    db = new Database( connection )
>    Connection.Close
>    Connection.Open
>    db.Open             --  The  server  will  rise  the  exception and
>                            terminate connection.
>


I find this to be unexpected, and I think other people will as well.   
But I can certainly live with it.  I hope this makes it into the  
documentation some day.

Charles Yeomans