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 Re: [WWD] Review of Final Chapters (5 and 6)
Date Wed, 03 May 2006 21:21:02 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>
> I think this is still confusing. I think you should add a comment 
> saying that the embedded driver must *not* be used to access the same 
> database from more than one JVM simultaneously. The multi-user 
> capabilities you are describing are (as far as I know) only valid if 
> all users use the same JVM/Derby system (i.e. the same instance of the 
> embedded driver), or if no users using different JVMs/Derby systems 
> access the same database at the same time.
Hi John -
Thanks again for your attention and feedback.  Both suggestions are well 
The sentence about the reason to create a client program is not well 
constructed and is inaccurate.  I also see that it does not carry the 
message I intended and I will rephrase it. 

The other note is what I think of as an 'endorsement of the embedded 
architecture'.  I included it to get people thinking / questioning along 
the lines you are, I have been successful in that regard.  I think it an 
important endorsement to make because I have seen many people new to 
Derby avoid embedded without really thinking it through.  It is my sense 
that the copious warnings about 'double booting' scares them away from 
embedded.  After working with Derby for awhile these people see that the 
embedded driver fully supports their need and is a cleaner and faster 
implementation.  I wanted to plant that seed of an idea.

It is arguable that the topic does not belong in an introductory 
document at all because it deals with system architecture as well as the 
specific meaning of terms like 'single-user', 'client-server', 
'networking' and 'interprocess communication'.  Clearing up the 
confusion is out of the scope of this document.  Your suggestion, 
however,  has me thinking I should draft a short paper on the topic that 
can be referred to when questions like yours are raised and will begin 
working on this.  Do you think this will help with the issue you raise?  
I hesitate to include the standard caution about access from 
multiple-JVMs as I perceive this as contributing to the mind-set that 
using the embedded driver is limiting. 

I would really like to hear your thoughts on this and maybe begin a new 
thread on the topic of when to use Network Server and when the embedded 
driver is sufficient.  It seems there is enough in this topic for a 
lively discussion.

View raw message