You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by Stanley Bradbury <St...@gmail.com> on 2006/04/29 00:26:24 UTC
[WWD] Review of Final Chapters (5 and 6)
The final chapters or the Working With Derby are available for review
and comment. Please take time to provide constructive feedback on
Chapters 5 and 6 - the review period will last at least a week (until
May 5).
The first four chapters have been committed and are available in the
documentation codeline. A PDF-format review copy of these chapters is
also attached to DERBY-913 and a download link is provided below for
those who like to perform a start to finish read of the document.
>>> Review copies of the document can be downloaded using the
following URLs:
New chapters 5 and 6:
http://issues.apache.org/jira/secure/attachment/12326037/ReviewPDF_wwdCh5and6rv1.0.zip
Committed Chapters 1 thru 4:
http://issues.apache.org/jira/secure/attachment/12325929/CheckCommitWWD-Ch1-4.pdf
-------- Original Message --------
Subject: [jira] Updated: (DERBY-913) [WWD] Proposal to create and add
Working With Derby, an activity-based tutorial document, to the Derby
documentation set
Date: Fri, 28 Apr 2006 22:16:40 +0000 (GMT+00:00)
From: Stan Bradbury (JIRA) <de...@db.apache.org>
To: Stan.Bradbury@gmail.com
[ http://issues.apache.org/jira/browse/DERBY-913?page=all ]
Stan Bradbury updated DERBY-913:
--------------------------------
Attachment: ReviewPDF_wwdCh5and6rv1.0.zip
ReviewSRC_wwdCh5and6rv1.0.zip
Initial reveiw files (rv 1.0) for Working With Derby Ch 5 and 6
>> Please review and send comments to derby-user@db.apache.org. Please code the subject line with '[WWD]'
ReviewPDF_wwdCh5and6rv1.0.zip - Contains the generated PDF and the program files needed to perform Activity 4 (Ch 5)
ReviewSRC_wwdCh5and6rv1.0.zip - The DITA source files to generate the review PDF
=== SNIP ===
Re: [WWD] Review of Final Chapters (5 and 6)
Posted by "Jean T. Anderson" <jt...@bristowhill.com>.
Stanley Bradbury wrote:
> I like the name - add mine to the votes for WorkingWithDerby.
> \Jean T. Anderson wrote:
>
>> ==== SNIP ==
>>
>> What about naming the Wiki page WorkingWithDerby?
>>
>> -jean
If I don't hear any objections (or better ideas) by tomorrow I'll go
ahead and change the DerbyInstruction Wiki page name to WorkingWithDerby.
-jean
Re: [WWD] Review of Final Chapters (5 and 6)
Posted by Stanley Bradbury <St...@gmail.com>.
I like the name - add mine to the votes for WorkingWithDerby.
\Jean T. Anderson wrote:
> ==== SNIP ==
>
>What about naming the Wiki page WorkingWithDerby?
>
> -jean
>
>
>
>
Re: [WWD] Review of Final Chapters (5 and 6)
Posted by "Jean T. Anderson" <jt...@bristowhill.com>.
Jean T. Anderson wrote:
> Stanley Bradbury wrote:
...
> <snip>
>
>>And now onto you question: A better name for DerbyInstruction here are
>>some off-the-top (if not off-the-wall) suggestions (I like DerbyHowTo as
>>well):
>>
>>DerbyCookbook - CookingWithDerby - DerbyRecipes - DerbyRecipebook
>>
>>ImplementingDerby - RunningWithDerby - DerbyKnowHow
>
>
> I'll toss out a few more:
>
> HowToUseDerby
> UsingDerby
> LearnDerby
> DiscoverDerby
> UnderstandDerby
>
> I think we want to be somewhat careful choosing a name since you'll link
> to it in the doc. --Would be inconvenient to change it later.
What about naming the Wiki page WorkingWithDerby?
-jean
Re: [WWD] Review of Final Chapters (5 and 6)
Posted by "Jean T. Anderson" <jt...@bristowhill.com>.
Stanley Bradbury wrote:
<snip>
> Thank you for pointing this page out - I like your suggestion but think
> it better to replace the main link at the beginning of the chapter
> (currently pointing to the 'Quick Start' page (QS)) with the more
> focused DerbyInstruction page (DI). What do you think?
I agree, especially since I populated the Quick Start from the
DerbyInstruction Wiki page.
<snip>
> And now onto you question: A better name for DerbyInstruction here are
> some off-the-top (if not off-the-wall) suggestions (I like DerbyHowTo as
> well):
>
> DerbyCookbook - CookingWithDerby - DerbyRecipes - DerbyRecipebook
>
> ImplementingDerby - RunningWithDerby - DerbyKnowHow
I'll toss out a few more:
HowToUseDerby
UsingDerby
LearnDerby
DiscoverDerby
UnderstandDerby
I think we want to be somewhat careful choosing a name since you'll link
to it in the doc. --Would be inconvenient to change it later.
-jean
Re: [WWD] Review of Final Chapters (5 and 6)
Posted by Stanley Bradbury <St...@gmail.com>.
Jean T. Anderson wrote:
>Stanley Bradbury wrote:
>
>
>>The final chapters or the Working With Derby are available for review
>>
>>
>>==== SNIP ===
>>
>>In chapter 6 you link to http://wiki.apache.org/db-derby/UsesOfDerby ,
>>and I think this is ok but that list kind of overwhelming with just a
>>few pointers on how to actually use a product with Derby.
>>
>>I had pulled some of the links for the Quick Start page [1] from
>>http://wiki.apache.org/db-derby/DerbyInstruction , which points to real
>>materials on how to do things. I think with some improvement it might be
>>a better candidate for linking to.
>>
>>I'll take a shot at reorgnizing the DerbyInstruction:
>> 1) I think it needs a flatter structure that makes it easier to find a
>>given product
>> 2) I don't like the name DerbyInstruction -- I find it too hard to even
>>remember it's there. What would be better? DerbyHowTo ?
>>
>>thoughts?
>>
>> -jean
>>
>>[1] http://db.apache.org/derby/quick_start.html#Next+Steps+for+Users
>>
>>
>>
Hi Jean -
Thank you for pointing this page out - I like your suggestion but think
it better to replace the main link at the beginning of the chapter
(currently pointing to the 'Quick Start' page (QS)) with the more
focused DerbyInstruction page (DI). What do you think? I would then
demote, so to speak, the QS link to paragraph text where QS is mentioned
(just before the location of the 'Uses of Derby' link (UOD)). I'd like
to leave the text mentioning UOD and encouraging people to add to it
but, after thinking about your comments, think that removing the link
from WWD would be wise. People who are really interested can seek out
the page but folks not sure where to go next won't be able to just click
through to it. I agree it is a mixed bag but I do like it from a PR
standpoint - it shows Derby is being adopted.
That is to say: I like telling people about UOD at the end of WWD as
they might be wondering where Derby fits within their environment.
Though the links on UOD will not talk directly about Derby the number of
entries show it is widely used. I think seeing this will provide a
level of confidence that Derby can be used in real-life situations.
And now onto you question: A better name for DerbyInstruction here are
some off-the-top (if not off-the-wall) suggestions (I like DerbyHowTo as
well):
DerbyCookbook - CookingWithDerby - DerbyRecipes - DerbyRecipebook
ImplementingDerby - RunningWithDerby - DerbyKnowHow
Re: [WWD] Review of Final Chapters (5 and 6)
Posted by "Jean T. Anderson" <jt...@bristowhill.com>.
Stanley Bradbury wrote:
> The final chapters or the Working With Derby are available for review
> and comment. Please take time to provide constructive feedback on
> Chapters 5 and 6 - the review period will last at least a week (until
> May 5).
<snip>
In chapter 6 you link to http://wiki.apache.org/db-derby/UsesOfDerby ,
and I think this is ok but that list kind of overwhelming with just a
few pointers on how to actually use a product with Derby.
I had pulled some of the links for the Quick Start page [1] from
http://wiki.apache.org/db-derby/DerbyInstruction , which points to real
materials on how to do things. I think with some improvement it might be
a better candidate for linking to.
I'll take a shot at reorgnizing the DerbyInstruction:
1) I think it needs a flatter structure that makes it easier to find a
given product
2) I don't like the name DerbyInstruction -- I find it too hard to even
remember it's there. What would be better? DerbyHowTo ?
thoughts?
-jean
[1] http://db.apache.org/derby/quick_start.html#Next+Steps+for+Users
Re: [WWD] Check of edits from : Review of Final Chapters (5 and 6)
Posted by "Jean T. Anderson" <jt...@bristowhill.com>.
This is my bad -- the web site is linking to workingwithderby.pdf
instead of to WorkingWithDerby.pdf. --I didn't catch the name change on
the web site.
fixing ....
-jean
Stanley Bradbury wrote:
> Daniel John Debrunner wrote:
>
>> The various versions of WWD at
>>
>> http://db.apache.org/derby/manuals/index.html#latest
>>
>> are out of date. The PDF version only has the first activity.
>>
>> Dan.
>>
>>
>>
>>
> Hi Dan -
>
> Thanks, I'll look into the PDF build problem - it should contain the
> first four chapters which have been committed. The HTML docs contains
> all four chapters so am hoping it is something simple with the PDF
> transform process. In the meantime you can use the verification copy of
> the PDF for Chapters 1-4 that is attached to Derby-913 - the download
> URL is:
>
> http://issues.apache.org/jira/secure/attachment/12325929/CheckCommitWWD-Ch1-4.pdf
>
>
> The final two chapters are near the end of the review period. I intend
> to submit the patch to be committed tomorrow barring new major issues.
> The initial draft without the changes from the review can be viewed by
> downloading:
>
> http://issues.apache.org/jira/secure/attachment/12326037/ReviewPDF_wwdCh5and6rv1.0.zip
>
>
> The changes are fairly minor - One: renaming the 'miscellanea' section
> and changing the links as described in my message to Jean:
> http://mail-archives.apache.org/mod_mbox/db-derby-dev/200605.mbox/%3c44569B46.3010005@gmail.com%3e
>
>
> Two: And rewritten two of the Activity notes as shown in:
> http://mail-archives.apache.org/mod_mbox/db-derby-user/200605.mbox/%3c445FE787.5070509@gmail.com%3e
>
>
>
>
Re: [WWD] Check of edits from : Review of Final Chapters (5 and 6)
Posted by Stanley Bradbury <St...@gmail.com>.
Daniel John Debrunner wrote:
>The various versions of WWD at
>
>http://db.apache.org/derby/manuals/index.html#latest
>
>are out of date. The PDF version only has the first activity.
>
>Dan.
>
>
>
>
Hi Dan -
Thanks, I'll look into the PDF build problem - it should contain the
first four chapters which have been committed. The HTML docs contains
all four chapters so am hoping it is something simple with the PDF
transform process. In the meantime you can use the verification copy of
the PDF for Chapters 1-4 that is attached to Derby-913 - the download
URL is:
http://issues.apache.org/jira/secure/attachment/12325929/CheckCommitWWD-Ch1-4.pdf
The final two chapters are near the end of the review period. I intend
to submit the patch to be committed tomorrow barring new major issues.
The initial draft without the changes from the review can be viewed by
downloading:
http://issues.apache.org/jira/secure/attachment/12326037/ReviewPDF_wwdCh5and6rv1.0.zip
The changes are fairly minor -
One: renaming the 'miscellanea' section and changing the links as
described in my message to Jean:
http://mail-archives.apache.org/mod_mbox/db-derby-dev/200605.mbox/%3c44569B46.3010005@gmail.com%3e
Two: And rewritten two of the Activity notes as shown in:
http://mail-archives.apache.org/mod_mbox/db-derby-user/200605.mbox/%3c445FE787.5070509@gmail.com%3e
Re: [WWD] Check of edits from : Review of Final Chapters (5 and 6)
Posted by "Jean T. Anderson" <jt...@bristowhill.com>.
Daniel John Debrunner wrote:
> The various versions of WWD at
>
> http://db.apache.org/derby/manuals/index.html#latest
>
> are out of date. The PDF version only has the first activity.
thanks for the catch. The html versions have everything that has been
committed to date, but there must be a problem with the pdf build.
-jean
Re: [WWD] Check of edits from : Review of Final Chapters (5 and 6)
Posted by Daniel John Debrunner <dj...@apache.org>.
The various versions of WWD at
http://db.apache.org/derby/manuals/index.html#latest
are out of date. The PDF version only has the first activity.
Dan.
Re: [WWD] Check of edits from : Review of Final Chapters (5 and 6)
Posted by Stanley Bradbury <St...@gmail.com>.
John, as always, your suggestions are helpful, thank you. I will use
your improved wording in quote 2.
[EOM]
John Embretsen wrote:
> Stanley Bradbury wrote:
>
>> John and other derby-users -
>>
>> I have rewritten the two the paragraphs mentioned above to address
>> the points made by John. Please let me know what you think.
>> quote 1 from "Activity notes", p.6 (8) REWRITE:
>> In a client / server environment the client program is often used
>> from other computers on the network. ...
>
>
> Sounds good, although it probably does not say everything you
> originally intended to say here.
>
>> quote 2 from "Activity notes", p.6 (8) REWRITE:
>> Derby's two architectures have caused confusion for some new Derby
>> users. They mistakenly think that embedded is a single user
>> configuration. This is not true. The embedded driver supports
>> multiple simultaneous connections, performs locking and provides
>> performance, integrity and recoverability. Any embedded application
>> can open multiple Derby connections and then provide a means for
>> multiple users to interact with the database on each connection. The
>> Derby Network Server is an example of such an application.
>
>
> Very good! Though I think the term "any embedded application" can be
> ambiguous. Is "any application using the embedded driver" better?
>
>
Re: [WWD] Check of edits from : Review of Final Chapters (5 and 6)
Posted by John Embretsen <Jo...@Sun.COM>.
Stanley Bradbury wrote:
> John and other derby-users -
>
> I have rewritten the two the paragraphs mentioned above to address the
> points made by John. Please let me know what you think.
> quote 1 from "Activity notes", p.6 (8) REWRITE:
> In a client / server environment the client program is often used from
> other computers on the network. ...
Sounds good, although it probably does not say everything you originally
intended to say here.
> quote 2 from "Activity notes", p.6 (8) REWRITE:
> Derby's two architectures have caused confusion for some new Derby
> users. They mistakenly think that embedded is a single user
> configuration. This is not true. The embedded driver supports multiple
> simultaneous connections, performs locking and provides performance,
> integrity and recoverability. Any embedded application can open multiple
> Derby connections and then provide a means for multiple users to
> interact with the database on each connection. The Derby Network Server
> is an example of such an application.
Very good! Though I think the term "any embedded application" can be
ambiguous. Is "any application using the embedded driver" better?
--
John
[WWD] Check of edits from : Review of Final Chapters (5 and 6)
Posted by Stanley Bradbury <St...@gmail.com>.
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>
==== SNIP ====
John and other derby-users -
I have rewritten the two the paragraphs mentioned above to address the
points made by John. Please let me know what you think.
quote 1 from "Activity notes", p.6 (8) REWRITE:
In a client / server environment the client program is often used from
other computers on the network. ...
quote 2 from "Activity notes", p.6 (8) REWRITE:
Derby's two architectures have caused confusion for some new Derby
users. They mistakenly think that embedded is a single user
configuration. This is not true. The embedded driver supports multiple
simultaneous connections, performs locking and provides performance,
integrity and recoverability. Any embedded application can open multiple
Derby connections and then provide a means for multiple users to
interact with the database on each connection. The Derby Network Server
is an example of such an application.
Re: [WWD] Review of Final Chapters (5 and 6)
Posted by Stanley Bradbury <St...@gmail.com>.
Thanks again John. I find dialog like this very helpful. I too am not
an expert but have talked to a lot of people who use Derby. It is very
possible, however, that the perceptions I have gotten are not the norm
so I appreciate questions and suggestions like you have posed.
Responses to a few specific points interspersed:
John Embretsen wrote:
> [SNIP]
> 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.
I am feeling fairly comfortable with the changes implemented in Derby to
prevent double-booting when using v 1.4 and higher JVMs. It is
certainly much harder to perform a double-boot now than when v 1.3 JVMs
were in common use. This is why I did not emphasis the issue in the WWD
document.
> [SNIP]
> 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
[SNIP]
I have saved this list and will try to address most, if not all, these
issues in the document I referred to earlier
Re: [WWD] Review of Final Chapters (5 and 6)
Posted by John Embretsen <Jo...@Sun.COM>.
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
Re: [WWD] Review of Final Chapters (5 and 6)
Posted by Stanley Bradbury <St...@gmail.com>.
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:
>
=== SNIP ==
Hi Craig -
Thanks for your response. I have taken this as an opportunity to start
an new thread to discuss the architectures since this does not seem to
directly relate the witting of the WWD document ( please let me know if
I am incorrect on this point). You can see the kick-off for the
discussion in the thread with subject:
Request for comments on deciding between implementing embedded or
client-server - (was: [WWD] Review of Final Chapters (5 and 6))]
As I indicate there I have sent an invitation to Derby-dev to join in on
this implementation discussion.
Re: [WWD] Review of Final Chapters (5 and 6)
Posted by Craig L Russell <Cr...@Sun.COM>.
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!
Re: [WWD] Review of Final Chapters (5 and 6)
Posted by Stanley Bradbury <St...@gmail.com>.
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.
Re: [WWD] Review of Final Chapters (5 and 6)
Posted by John Embretsen <Jo...@Sun.COM>.
Stanley Bradbury wrote:
> Attachment: ReviewPDF_wwdCh5and6rv1.0.zip
> ReviewSRC_wwdCh5and6rv1.0.zip
>
> Initial reveiw files (rv 1.0) for Working With Derby Ch 5 and 6
> >> Please review and send comments to derby-user@db.apache.org. Please
> code the subject line with '[WWD]'
I have a couple of small comments to the "Activity notes" in Activity 4
in the Ch. 5 and 6 PDF, v1.0, available for download at
http://issues.apache.org/jira/browse/DERBY-913. I am sending these
comments to derby-user only.
<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.
--
John