db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stanley Bradbury <Stan.Bradb...@gmail.com>
Subject Request for comments on deciding between implementing embedded or client-server - (was: [WWD] Review of Final Chapters (5 and 6))
Date Wed, 03 May 2006 23:57:22 GMT
Starting spin-off thread on derby-user and inviting derby-dev readers to 
participate - see the attached thread for the current state of the 
DERBY-DEV  readers: please help centralize this discussion by replying 
and monitoring  this topic on DERBY-USER.
OVERVIEW:  The ability to easily implement Derby in different 
architectures differentiates Derby from most other RDBMS systems.  
Helping people understand the benefits and costs of each of the Derby 
implementation architectures is important to the successfully using 
Derby.  Please share your experiences regarding the pros and cons of 
using Derby in embedded and client-server architectures.

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 this should be included there.  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 will 
cc derby-dev on this message and ask for input on this thread (I think 
this topic is worth the cross-post).

View raw message