db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Embretsen <John.Embret...@Sun.COM>
Subject Re: [WWD] Review of Final Chapters (5 and 6)
Date Thu, 04 May 2006 09:39:33 GMT
Stanley Bradbury wrote:


> 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.

Good, thanks!

> 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.

I see your point and I largely agree. I took your bait when I read that paragraph, but I am
not sure Derby-newbies would do that as easily (unless they already know the relevant sections
of the manuals). (For the record, I consider myself neither a newbie nor an expert when it
comes to Derby ;) ) I think the reason I started thinking about it was that you seemed to
claim that there are virtually no limitations to the multi-user/multi-connection abilities
of the Derby embedded driver. However, I
see that you leave room for exceptions to the rule... Perhaps it is better to encourage people
try it out, than to scare them off with warnings of what _might_ happen if they do this and
that. Of course, users who (willingly or accidentally) double-boot a database risk corrupting
their data, but the manuals have that covered.

> 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?  

Yes, I think a document explaining the basics (and more) of the different architectures/frameworks
would be useful, and better than including it all in the WWD document. Most of it is covered
in the manuals, the web tutorial or elsewhere, but I miss a document where all the different
embedded/client/server configurations are discussed and compared, such as:

  a) Pure embedded Derby
  b) Derby client/server, including:
    b.1) Derby "stand-alone" server framework
    b.2) Derby "embedded server" framework
      b.2.1) Managing the embedded server using the API
      b.2.2) Managing the embedded server using system properties and the embedded driver
      b.2.3) Accessing Derby in this configuration using the embedded driver
      b.2.4) Accessing Derby in this configuration using the client driver

> 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 was not aware of such a strong presence of skewed derby mindsets, but I am sure you are
correct ;) I do _not_ insist that you include the warning.

> 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.

Sure, that was a good initiative. I will participate if/when I feel I have something to contribute.


View raw message