Starting New thread from the following :
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:Craig.Russell@sun.com
> 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 then 'embedded server' should be include.
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 have sent an invite to join this new thread to
derby-dev (I think this topic is worth the cross-post).
|