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???
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 ]
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 by:autobot
Right! We're on it! Let's get to work tiny ad!
a bit of art, as a gift, that will fit in a stocking