Are you asking about the SCJD assignment, and making the assumption that this assignment uses an SQL server? If so, then your initial assumption is wrong - the SCJD assignment does not use a SQL server: you are given a proprietary binary file from Sun, and you must develop Java classes that will do database like operations on this file (create, read, update, delete, search).
Or are you asking a work/school/personal question, where you are starting with a SQL database and trying to determine whether you need a locking scheme similar to the ones in use here? If so, then the answer is a little harder to come by. In some cases the database itself can handle some of the locking issues for you, but you will almost certainly need to build classes to handle business logic, and sometimes you may need to handle who "owns" a record within your business logic.
Assuming we have a real relation database like SQL Server which provides all kinds of locking feature, do we need a locking mechansim such as what SCJD candidates are doing.
Yes, you would still need a locking mechanism even if a real RDBMS was used. If multiple users are decrementing an integer field in a database record (as a result of booking a contractor or a flight), the SQL Server would not prevent the users from "overbooking" that flight or the contractor. Here is the scenario that will be equally the same, whether you use RDBMS or a flat file.
Thread1: User 1 reads the number of available airplane seats left on flight A100, it turnes out to be 2.
Thread2: User 2 reads the number of available airplance seats left on flight A100, it is still 2.
Thread1: User 1 initialtes the transaction by booking 2 seats.
Thread2: User 2 initialtes the transaction by booking 2 seats.
Thread1: transaction completed, seat count decremented to 0.
Thread2: transaction completed, seat count decremented to -2.
The plane is overbooked.
Joined: Sep 29, 2004
Thanks John. I almost completed my SCJD but currently working on a real life application. I would like use what I have learned fron SJCD in my real app.
1. Thread A does a search and gets a bunch of results. If Thread B makes a change to a particular flight or record, HOW do I inform Thread A that the record is modified and it needs to refresh to get the latest data. Will Oberverable/Observer work OR can the server inform all clients that data have changed. How do I implement this?
2. I think in a real life app, even read process should be locked. My locking mechanism must now be very elaborate instead of just locking record no. I need to lock the actual client which is doing database operations. Can I sent an instance of the client to the server and lock it. I think RMI server can give me the client ID.
As you can see real life applications can get complicated.
Originally posted by Reza Rahman: I wonder if this is an appropriate question for this forum.
I am not sure if it is appropriate for this forum either, but as long as the questions are expressed in terms of the assignment, then there is no problem. Besides, I am not sure where to move this to otherwise (JDBC forum, or Distributed Java forum, or OO, Patterns, UML and Refactoring, or ???)
Originally posted by GD Deepz: 1. Thread A does a search and gets a bunch of results. If Thread B makes a change to a particular flight or record, HOW do I inform Thread A that the record is modified and it needs to refresh to get the latest data. Will Oberverable/Observer work OR can the server inform all clients that data have changed. How do I implement this?
First you need to decide whether you really need this. In real life, airline carriers and hotel reservations systems do not notifiy clients about changes to records. The systems usually work on multi step process, typically "check availability" followed by "book seats" where the second step could fail if the availabily dropped below requested seats between first and second steps. (For those who work in these industries, yes I know there are "long sells" etc., but lets keep it simple ).
If you do decide that this is needed / desirable, you will probably find that the Observable pattern will be quite good for you - clients who want to be updated can register themselves as observers, but clients who are not interested don't have to.
From memory, if you are using RMI, you may need to implement your own form of the Observable pattern rather than using the inbuilt Observer and Observable classes and interfaces (it is very simple). Then you will need the Observer side of the client to implement Remote so that it can be called from the server. Finally just call your addObserver method with the client's Remote class and you are all set up. Whenever the server wants to update a client it can.
If you are using sockets, or some other protocol, you may find that you can use the inbuilt Observer/Observerable classes and interfaces.
Originally posted by GD Deepz: 2. I think in a real life app, even read process should be locked. My locking mechanism must now be very elaborate instead of just locking record no. I need to lock the actual client which is doing database operations. Can I sent an instance of the client to the server and lock it. I think RMI server can give me the client ID.
Why do you need to lock the client?
You may find that the new Read/Write locks available in JDK 5 may help here. Quite often all you need in such a case is to know that while one or more clients have a read lock, then no client may get a write lock. In such a case you don't normally need to know which client has the read lock.
Regards, Andrew [ June 11, 2005: Message edited by: Andrew Monkhouse ]