db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig L Russell <Craig.Russ...@Sun.COM>
Subject Re: [WWD] Review of Final Chapters (5 and 6)
Date Wed, 03 May 2006 21:48:47 GMT
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.


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!

View raw message