Server Design

[Terry McKee]

I see that many people are associating a single Data object with a Server...using the singleton pattern. I am confused by this. Shouldn't different client's be able to use different datasource's simultaneously?

[Marco Barenkamp]

Hi,
due to the fact, that the server is a remote Server,
it will always be a singleton because every client
will lookup the same server instance.

[Terry McKee]

I understand that the server should only have 1 instance, but shouldn't the server contain references to multiple Data references?
Example:

Client A -> connects to -> Server A -> connects to Data Source A
Client B -> connects to -> Server A -> connects to Data Source B

How are people approaching this issue?

[Peter den Haan]

I agree completely with Terry. Singleton is one of the most abused patterns and here, as so often, completely inappropriate. Come on, how often have you used a database with exactly one table?
- Peter

[Jack Zhang]

A single datasource does not necessarily mean only one table. If you allow multiple objects to open the same file, how could you provide record locking?
-- Jack

[Terry McKee]

<code>
A single datasource does not necessarily mean only one table. If you allow multiple objects to open the same file, how could you provide record locking?
</code>
My initial thought about how to approach this is basically to have a server that contains some kind of collection that holds references to Data objects and the canonical paths to those datasources. When a client connects with the server the collection is checked to see if the passed file is already established within the collection. It doesn't have to be more complicated than that. I am not going to add any kind of timing out feature if a client gets disconnected from the server without closing first. But I really think that it is an important design decision that shouldn't be overlooked.

[Terry McKee]

One item that I might add is that the collection that contains references to the canonical path of the datasource as well as the reference to the datasource would also have to have a count of client's referencing it. This is so that if 2 clients are pointing to the same data reference and client 1 closes the collection still maintains a reference to the datasource for client 2.

[mitchner green]

Terry, I considered that also. I thought about creating different instances of the Data classes, different instances of the Lock class and so on. Then I thought about all the complication I was adding to meet that requirement. ugh. Plus trying to test that would be a pain.
I went back and re-read the assignment and decided not to deal with that issue at all. There is no requirement stating we have to. I think it is "out-of-scope".
When my server is running, a client connects to whatever file the server is using. A network client can't choose a different file.
Of course, when running in "stand-alone" mode, or when starting the server, a file can be chosen.
That is what I decided.

[Peter den Haan]

Originally posted by Jack Zhang:
A single datasource does not necessarily mean only one table. If you allow multiple objects to open the same file, how could you provide record locking?

Multiple objects should not open the same file. What I object against is everything with the words "Data" and "Singleton" in one sentence. Data implements a table. If you make Data a singleton, you are making an architectural mistake that may be hard to fix later. Even if the current implementation supports no more than one table, don't do it.
- Peter

[This message has been edited by Peter den Haan (edited September 19, 2001).]

[Terry McKee]

Mitchner,
So in your design clients would be able to choose the filename if they were in local mode OR the host and port if they were in remote mode...interesting. I assume that you have some kind of property that tells the server on startup where to point for the datasource?

[mitchner green]

At server start-up (or local mode startup) the filename ("db.db") is one of the arguments. Actually, I think my design will support one server using db.db on one port while another server uses another filename on another port.
I say "I think" that is supported because I haven't tested that scenario. Maybe I'll give it a try and see what happens...
My server arguments are: database file name, host name, port #. "default" can be entered for host and port to use 127.0.0.1 and 1099. If only one argument is provided, the server and client both start in that VM.
On the client the arguments are host and port only. Again, "default" can be entered to connect to 127.0.0.1/1099.

[vladimir levin]

Data is not really a table. Data is a class which implements
database operations of the read, create, update, delete
variety. It is like some of the API's that you'd see in the
1980's in my opinion, like clipper. Of course a real database
system will not just provide methods like this, it would
have a relational database language -- SQL. Anyway, my point
is that in theory the Data class could perform operations
on multiple 'tables'. There should be only one instance of
the Data class on the server, and all client threads should
concurrently execute methods of the Data class. That being said, one does not
*have* to implement the Data class as a
singleton. It is reasonable, I think, to
just create one instance of it in the server.

Originally posted by Peter den Haan:

Originally posted by Jack Zhang:
[b]A single datasource does not necessarily mean only one table. If you allow multiple objects to open the same file, how could you provide record locking?

Multiple objects should not open the same file. What I object against is everything with the words "Data" and "Singleton" in one sentence. Data implements a table. If you make Data a singleton, you are making an architectural mistake that may be hard to fix later. Even if the current implementation supports no more than one table, don't do it.
- Peter

[This message has been edited by Peter den Haan (edited September 19, 2001).][/B]

[This message has been edited by vladimir levin (edited September 21, 2001).]

[Terry McKee]

A couple of things,
First, I agree with Vladimir that the Data class should not be a Singleton. I don't think that the server should be a Singleton either. It just doesn't make since. If you want to programatically start two instances of servers up at the same time it should be fine. Either they point to differend Data instances OR 1 server will throw an exception if it is trying to point to the same Data instance.
Second to Mitchner,
You wrote:
My server arguments are: database file name, host name, port #.
Perhaps I just don't understand. I can understand that you pass the file name to the server. But the host name and port number would be passed from the client. Wouldn't it?