db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stanley Bradbury <Stan.Bradb...@gmail.com>
Subject [WWD] Check of edits from : Review of Final Chapters (5 and 6)
Date Tue, 09 May 2006 00:51:19 GMT
John Embretsen wrote:

> ===   SNIP  ====
> <quote 1 from "Activity notes", p.6 (8)>
> A client program is often created to allow database access and updates 
> from multiple computers on the network.
> </quote>
>
> I don't think this statement is correct. It is not the "client 
> program" that allows access from multiple computers, it is the server 
> framework that does this. Would you like to rephrase?
>
>
> <quote 2 from "Activity notes", p.6 (8)>
> Derby's two architectures have caused confusion for some new Derby 
> users. They mistakenly think that embedded is a single user 
> configuration. Not true. The embedded driver supports multiple 
> simultaneous connections, performs locking and provides performance, 
> integrity and recoverability.
> </quote>

====  SNIP  ====

John and other derby-users -

I have rewritten the two the paragraphs mentioned above to address the 
points made by John.  Please let me know what you think. 

quote 1 from "Activity notes", p.6 (8)  REWRITE:
In a client / server environment the client program is often used from 
other computers on the network. ...

quote 2 from "Activity notes", p.6 (8) REWRITE:
Derby's two architectures have caused confusion for some new Derby 
users. They mistakenly think that embedded is a single user 
configuration. This is not true. The embedded driver supports multiple 
simultaneous connections, performs locking and provides performance, 
integrity and recoverability. Any embedded application can open multiple 
Derby connections and then provide a means for multiple users to 
interact with the database on each connection. The Derby Network Server 
is an example of such an application.



Mime
View raw message