Stanley Bradbury wrote:
[SNIP]
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.
--
John
