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

[Ivan Smahin]

Hello Ruslan,

Wednesday, December 13, 2006, 11:09:36 AM, you wrote:

> On 12/06/12 8:37 PM, "Charles Yeomans" <charles ÎÁ 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.

>> 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".


>> 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.
   

>> VConnection.Destructor should call VConnection.Close.

> AGREE. Ivan please confirm this.
>
Yes.



-- 
Best regards,
 Ivan                            mailto:ivan_smahin ÎÁ valentina-db.com