Mailing-List: contact derby-user-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Derby Discussion" <derby-user@db.apache.org>
Received-SPF: neutral (asf.osuosl.org: 32.97.182.146 is neither permitted nor
 denied by domain of Stan.Bradbury@gmail.com)
Message-ID: <44594488.6000008@gmail.com>
Date: Wed, 03 May 2006 17:02:16 -0700
From: Stanley Bradbury <Stan.Bradbury@gmail.com>
User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923)
MIME-Version: 1.0
To: Derby Discussion <derby-user@db.apache.org>
Subject: Request for comments on deciding between implementing embedded or
 client-server - (was: [WWD] Review of Final Chapters (5 and 6))]
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Starting New thread from the following :

Craig L Russell wrote:

> Hi Stan,
>
> When you get around to discussing architecture issues, you might make  
> sure you get feedback from the derby experts. My understanding is  
> that you can use the embedded Derby with both same-vm clients and  
> outside-vm clients by starting the network server when you start the  
> embedded database.
>
> Craig
>
> On May 3, 2006, at 2:21 PM, Stanley Bradbury wrote:
>
>> 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 taken. 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.
>>
>>
>>
>>
>
> Craig Russell
> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
> 408 276-5638 mailto:Craig.Russell@sun.com
> P.S. A good JDO? O, Gasp!
>
Hi Craig -
You are correct. There is what has been termed the 'embedded server' 
architecture as well but this is well out of the scope of a introductory 
document like WWD. 

However, since I hope to spin-off a thread discussing the various 
implementation architectures then 'embedded server' should be include.  
And thanks for the suggestion on including derby-dev - even though this 
is an implementation architecture issue (hence more germane to 
derby-user) I think there are derby-dev people who will want to 
participate.   I have sent an invite to join this new thread to 
derby-dev (I think this topic is worth the cross-post).