• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Running server and client at the same time

 
Anna Hays
Ranch Hand
Posts: 131
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I remembered someone said they can't be bothered to put thread safety in db code for standalone client. I am wondering, if your application is ran as a server, then you ran as standalone as well. What would be the thread issues???
More interestingly, you ran it as a server, standalone and network at the same time. I am doing this config property thing now. I have the issues that, if I only set 1 port, would all the 3 mode has to use the same one? What if I want to start a server, then I want to use anther DB remotely? Hmmm or do I have to care about all these???
 
Javini Javono
Ranch Hand
Posts: 286
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,
Within my "Preferences File" I have each element name prefixed
to denote whether the client or server is running; for example:
CLIENT_DATABASE_TYPE = "URLY_BIRD"
SERVER_DATABASE_TYPE = "BOOK_RENTAL"
This may or may not address some aspect or aspects of your
question.
For your complex scenario, it does seem that on one computer
the following activities could be carried out by one person wherein
this one person is logged on only to one account within this
one computer:
1. Start the server which serves up database1.
2. Start a client which uses RMI to access database1.
3. Start another client which locally accesses database2.
Each of the above three scenarios are done, however, within
separate JVM's. And, if these three activities were all started
within the same directory, then there would only be one
preferences file used. If the one user of the computer could
type infinitely fast then maybe there may be threading issues
concerning the properties file (I'd have to look at the Properties
class to see if it is thread safe). My code, as currently written,
uses the properties file as a store; so, with two simultaneous
users attempting to make a connection to different databases
from the same user account, it could be possible for confusion
to result; I might just document that behavor may be unpredictable
under these circumstances.
Concerning your question about local mode and multi-threading.
For my particular system, before I made revisions, so I need to
recheck this, it as possible for one local client application to request
N "Data's" or local connections, and then have all the "Data's" run
simultaneously; this was because each "Data" or connection was a
new instance.
But, my software (again I'll have to check, and certainly
I'll have to document this), probably would not support a client
using only one "Data" connection and multi-threading on that
one instance.
I may not have actually answered your questions; but, simply "talking
with you," which may or may not be helpful. That is, restating, and
perhaps clarifying your question or clarifying the issues as I see them.
Perhaps others will have sharper insights into your concerns.
Thanks,
Javini Javono
[ April 23, 2004: Message edited by: Javini Javono ]
 
Min Huang
Ranch Hand
Posts: 100
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Anna,
You may assume that at any moment, at most one program is accessing the database file; therefore your locking system only needs to be concerned with multiple concurrent clients of your server.

The assignment states (above) that you are to assume only one program is accessing the database file at any given time. Therefore, you don't have to worry about a standalone client using the same database file as the server. If you really want to worry, you can put a file lock on the database file when your server starts
The operating mode is selected using the single command line argument that is permitted. Architecturally, this mode must use the database and GUI from the networked form, but must not use the network server code at all.

Also, there is some concern as to whether or not the standalone client should lock/unlock records. From the quote above, that seems to indicate that the standalone mode should lock and unlock records as well, as if the only difference between standalone and client mode is that the network connection is lifted out of standalone mode.
There's no mention that the standalone mode should specifically *not* lock or unlock, so taking that out would just generate extra work for you
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic