Starting spin-off thread on derby-user and inviting derby-dev readers to
participate - see the attached thread for the current state of the
discussion.
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:[EMAIL PROTECTED]
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).
