After browsing through this forum, I am still confused about the local and remote connections as I realize there are two ways of interpreting the requirement. It seems to be that scenario 2 is more practical than scenario 1 as you could have a client running at the server, or perhaps server also acting as a client itself in the real world. I am not sure whether scenario 2 is what we need to implement. Scenario 1 ========== There are multiple remote clients accessing the database server (remote connection). Each remote client also has its own local database which it can access. This local db access does not require any TCPIP support. Scenario 2 ========== There are multiple remote clients accessing the database server (remote connection). There is also a client (we name it B)running at the database server. Since the client B and the database server are running at the same machine, this client B does not require TCPIP to access the database, and thus it is a local connection.
Rudy: I think you are reading way to much into the requirement. When it says local mode, what it means (IMHO) is that one client accessing the db.db file. Like using MS Word on your desktop. When it says network mode, what it means (IMHO) is that several clients, from different machines, accessing the db.db file, like a web application. Of course, in this case, you need some type of database server. In terms of design, this is what I think of these requirements: Local mode, the GUI client directly access the class files, namely, Data.class, etc. Network mode, the GUI client calls the data client, which in terms calls the database server on a remote machine. Any SCJDs out there willing to help out on this issue?
Ya, Even I think the same as Adrian said... In Local mode, Client/GUI directly connects to the database and both will be in the same machine. In network mode, client sends the requests to the server and server connects and retrieves the reqd info from database on behalf of the cleint. If there is any mistake in my understanding, please correct me. Thanks, Srilatha.
Adrian, The reason why I am raising this issue is because the development approach between case 1 and case 2 are completely different. In case 1, you need to utilize the data class to access the local database, but in case 2 you need not. In case 2, the local connection or precisely the local database access is still confined to the client-server model (you do not need to implement data classes on the client side compared to case 1), but it just happens that the client and server are running on the same machine. Basically the database access mechanism will be the same for both the remote or local connection. The only difference is the bypass of the network connection as mentioned in the specification.
Rudy, I understand your point, that's what I thought originally too. However, after some brainstorming, I came to the conclusion that when we talk about client/server model, we are talking about the design. The requirement never mentioned anything about provide concurrent support (no the thread locking) of both local and remote at the same time. In your scenario 2, I think you mean having a server, several other machines are accessing the data server at the same time (remote access). While having a user sitting at the server machine, and accessing the database using local mode at the same time. This will cause some issues with concurrency, etc. From what I understand of my requirement, however, it seems to me that the application runs in one of the two mode, but never running two mode together. Any comments?
The client may not run in the 2 modes concurrently but the data server should be able to support both modes of access. Question is whether the it is required. The difference boils down to supporting transactions in local mode. Thread safety should be taken care of on the data server. Sam [This message has been edited by Sam Wong (edited February 13, 2001).]
girl power ... turns out to be about a hundred watts. But they seriuosly don't like being connected to the grid. Tiny ad:
a bit of art, as a gift, the permaculture playing cards