permaculture playing cards*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes Locking a record Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Murach's Java Servlets and JSP this week in the Servlets forum!
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "Locking a record" Watch "Locking a record" New topic
Author

Locking a record

Keith Jones
Ranch Hand

Joined: Oct 30, 2006
Posts: 105
Hi all,

I'm a bit confused on how the locking is to work in the B&S application. The database file has an 8 digit field for recording the customer id of the person who has locked this record.

1. Does that mean that my lock method should look like this:



2. How do I assign customer numbers to the clients (ensuring that they are unique)?

Thanks


SCJP 1.4
Mike Ngo
Ranch Hand

Joined: Oct 16, 2006
Posts: 89
The customer Id is typed in by the CSR when they book a room. When a room is booked, the customer Id field is used to store the Id of the customer who has booked that room. The customer Id field is not used for locking.
Keith Jones
Ranch Hand

Joined: Oct 30, 2006
Posts: 105
Hi Mike,

I think you must be doing a different one from me as the B & S paper does not refer to booking rooms and there is no stipulation that says that the CSR enters the customer id. Thanks for your help though.

Does anyone know if we are meant to reserve a contractor for our customers by entering their customer id into the database file? After all that is what the field entry is for.
Keith Jones
Ranch Hand

Joined: Oct 30, 2006
Posts: 105
Oh and I think I may have not been clear about locking. What I meant to ask was if the customer id is supposed to be used to lock a record so that no one else can use the same contractor (room on your project).

Cheers
Mike Ngo
Ranch Hand

Joined: Oct 16, 2006
Posts: 89
Well I am working on URLyBird. But I am pretty sure that's how customer ID is used in your project. In general, if the customer Id field is empty, that record is available. If it is not empty, that record is not available.
Locking should not be using the database file at all.
Keith Jones
Ranch Hand

Joined: Oct 30, 2006
Posts: 105
Hi Mike,

I think I understand what you mean. I agree that an empty field for customer id means that the contractor/room is available and one that is not empty means that it is booked.

However, let me see if we are on the same wavelength.

1. The lock method calls isLocked to see if the record is locked.
2. If it is then wait
3. Else lock
4. Step 3 entails opening the database file and looking for the record
5. When you find the record you put the customer id into the relavant field of that record

Is this what you understand by the requirement?
Mike Ngo
Ranch Hand

Joined: Oct 16, 2006
Posts: 89
There should be no steps 4 and 5. The locking should involve steps 1-3 only.
Keith Jones
Ranch Hand

Joined: Oct 30, 2006
Posts: 105
Hi Mike,

Are you sure? Step 3 is the step where we lock the record. The specification says that the database file contains an indication that a record is locked by having the id of the customer in a paraticular field of that record. Now, surely we must carry out steps 4 and 5 in order to populate that field of that record so that it becomes booked. Am I not right there? Otherwise how would we know next time if that record is locked?

I understand that we could maintain our own array,list,arraylist,vector or whatever we like of locked records but then what would be the point of having the information about who has booked a particular record in the database?

Mike Ngo
Ranch Hand

Joined: Oct 16, 2006
Posts: 89
Looks like your project differs from mine. Can you post that section?
Sorry, I am speaking from a generic record locking algorithm.
Keith Jones
Ranch Hand

Joined: Oct 30, 2006
Posts: 105
Well,

Under the Database Schema section in the spec is described the last field of a record. Here's what it says:

Field descriptive name

Customer holding this record

Database field name

owner

Field length

8

Detailed description

The id value (an 8 digit number) of the customer who has booked this. Note that for this application, you should assume that customers and CSRs know their customer ids. The system you are writing does not interact with these numbers, rather it simply records them. If this field is all blanks, the record is available for sale.

Are you using an array or something else to store your booked records?
Mike Ngo
Ranch Hand

Joined: Oct 16, 2006
Posts: 89
Exactly the same spec but for different application.
So you should not have step 4 and 5.

You should use Hashtable or HashMap (depends on how you synchronize your code) because you want a store a pair (recNo, lockCookie)
Keith Jones
Ranch Hand

Joined: Oct 30, 2006
Posts: 105
Originally posted by Mike Ng:
Exactly the same spec but for different application.
So you should not have step 4 and 5.

You should use Hashtable or HashMap (depends on how you synchronize your code) because you want a store a pair (recNo, lockCookie)


Ok,

two questions.

1. What is this cookie thing?
2. If our specs say the same thing then why have we interpreted it differently? From what I can see the way in which we tell if a record is booked is by looking at the file and checking under that record. The way in which we could let others know that a record is booked is by putting a customer id in the file. If that functionality is there then why do we need to create our own? I really don't get something here.



Mike Ngo
Ranch Hand

Joined: Oct 16, 2006
Posts: 89


1. What is this cookie thing?


Well, I think Sun uses the work "cookie" too many times and it makes it confusing. In my code, I don't even use it for my variable name.
It is a unique number (Id) that your application generates.
If you are doing database stuff, you will see it all the times... customer Id, employee Id,...

In this particular application, it is a number your application generates to be associated with a lock.



2. If our specs say the same thing then why have we interpreted it differently? From what I can see the way in which we tell if a record is booked is by looking at the file and checking under that record. The way in which we could let others know that a record is booked is by putting a customer id in the file. If that functionality is there then why do we need to create our own? I really don't get something here.



That is because earlier you mix up booking and locking. You look at the field in the file to see if the record is BOOKED or not.
You don't look at it for record locking. Locking is to guard access to a shared resource. Your Lock object should be generic to guard anything.

I would step back and implement the updateRecord() or deleteRecord() first.
In fact, I would implement lock() and unlock() last.
Keith Jones
Ranch Hand

Joined: Oct 30, 2006
Posts: 105
Originally posted by Mike Ng:


That is because earlier you mix up booking and locking. You look at the field in the file to see if the record is BOOKED or not.
You don't look at it for record locking. Locking is to guard access to a shared resource. Your Lock object should be generic to guard anything.

I would step back and implement the updateRecord() or deleteRecord() first.
In fact, I would implement lock() and unlock() last.


Hi Mike,

Thanks for all your help. I'm still a little confused but I'll take your advice and implement the updateRecord first. You'll be telling me next that we don't have to modify the database file in order to update the record!

Ok so you remember that step 1 was:


1. The lock method calls isLocked to see if the record is locked.


I'm sorry for using the word lock when i meant book but from what I can tell the isLocked method should open the file and check the field to see if the record is BOOKED and then the if it isn't we should open the file and BOOK it. I still don't see why we have have to maintain a HashTable.

Also updateRecord does modify the file doesn't it?
Mike Ngo
Ranch Hand

Joined: Oct 16, 2006
Posts: 89
yes. updateRecord() will update the file. Write it and you will see everything fall into place and why you need hashtable or map.
Keith Jones
Ranch Hand

Joined: Oct 30, 2006
Posts: 105
thanks Mike,

I will do that but I still think that if the update method writes to the file then so should the lock method. Anyway, I'll write that method first.

1. Can I use RandomAccessFile because the spec says:

"All numeric values are stored in the header information use the format of the DataInputStream and DataOutputStream classes. All text values, and all fields (which are text only), contain only 8 bit characters, null terminated if less than the maximum length for the field. The character encoding is 8 bit US ASCII."

2. From what I can see US ASCII is 7 bit so what's this about?

Cheers
Mike Ngo
Ranch Hand

Joined: Oct 16, 2006
Posts: 89
The doc of DataInputStream says bit 7 is zero so they are essentially the same. You can use RandomAccessFile.
Keith Jones
Ranch Hand

Joined: Oct 30, 2006
Posts: 105
Thanks Mike you've been very kind and helpfull.
Mark Smyth
Ranch Hand

Joined: Feb 04, 2004
Posts: 288
Originally posted by Keith Jones:


I'm sorry for using the word lock when i meant book but from what I can tell the isLocked method should open the file and check the field to see if the record is BOOKED and then the if it isn't we should open the file and BOOK it. I still don't see why we have have to maintain a HashTable.

Also updateRecord does modify the file doesn't it?


You lock and unlock a record when you want to update a particular record in the database. isLocked should just check to see if the record is deleted or if it is valid, and then check if it is already locked.

The locking methods have no idea what data is contained within in a record and so know absolutely nothing about booking a room, it is their job to ensure that two clients are not updating a record at the same time.

While it is not a requirement of the exam to implement the functionality for the GUI, from the point of view of the db class an update could just as easily be changing the name, location, date or any of the other record fields, not nescessarly just booking.

Suppose that two clients want to update a record. Client A to change the price of the record and Client B wants to book the (room/contractor) . The client A calls lock to lock the record. The client B then calls lock but is blocked from progressing as the record is locked by the first method. The client A proceeds to change the price and unlocks the record. Only then is client B is then allowed to lock the record and book the room and unlock.


SCJP<br />SCJD
Keith Jones
Ranch Hand

Joined: Oct 30, 2006
Posts: 105
That's made it much clearer thanks
Rudolph Jen
Ranch Hand

Joined: Nov 17, 2006
Posts: 37
Thanks for all that information.

You talked about the locking, to ensure, that the data is not corrupted in any way.

But what is about the records the GUI displays des CSR?

1. CSR1 searchs for 'Heating' and gets recNo 1,2,7,10 displayed
2. CSR2 also searchs for 'Heating' and also gets recNo 1,2,7,10 displayed
3. CSR1 and his caller decide for recNo 2
4. CSR1 update record 2 in dataFile with customerId of his caller.
5. CSR2's caller also would like to get record 2 now. But it is not available anymore. CSR2 has to say "Sorry for that. Some one was faster than you. Are you interessted in the others? And it still can be possible, that he has to try several times (in case a lot of caller asks for 'Heating').

I know, that the only way would be that CSR1 locks all 'Heating' records, just to display. CSR2 has to wait now until CSR1 has finished his telephon call. But this would be a huge negative performance break.

My question: What do you think about this???

Rudolph


SCJP<br />SCJD (in progress)
Rudolph Jen
Ranch Hand

Joined: Nov 17, 2006
Posts: 37
Solution: optimistic locking

And yes: it can happen, that CSR2s caller has bad luck. It is not possible otherway.
Mark Smyth
Ranch Hand

Joined: Feb 04, 2004
Posts: 288
Originally posted by Rudolph Rendeer:
Thanks for all that information.

You talked about the locking, to ensure, that the data is not corrupted in any way.

But what is about the records the GUI displays des CSR?

1. CSR1 searchs for 'Heating' and gets recNo 1,2,7,10 displayed
2. CSR2 also searchs for 'Heating' and also gets recNo 1,2,7,10 displayed
3. CSR1 and his caller decide for recNo 2
4. CSR1 update record 2 in dataFile with customerId of his caller.
5. CSR2's caller also would like to get record 2 now. But it is not available anymore. CSR2 has to say "Sorry for that. Some one was faster than you. Are you interessted in the others? And it still can be possible, that he has to try several times (in case a lot of caller asks for 'Heating').

I know, that the only way would be that CSR1 locks all 'Heating' records, just to display. CSR2 has to wait now until CSR1 has finished his telephon call. But this would be a huge negative performance break.

My question: What do you think about this???

Rudolph


I think that problem is similar to that of web based e-commerce systems, in that suppose you are at an online bookstore and there is one copy of a book left, you put it in your shopping cart. Then you go off and browse for more books and add them to the cart also. By the time you get to checkout there is no guaranntee that the book is still available. I think that it is beyond the scope of the assignment to devise a scheme to guard against stale data, I don't think that locking all records for the possibility of a future booking is a good idea and I think that this could be risking losing alot of marks.
Mark
Rudolph Jen
Ranch Hand

Joined: Nov 17, 2006
Posts: 37
I agree. Let's forget about that ;-)

The GUI has only to be pepared, to show a message if customerId-field is not null anymore.

Rudolph
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Locking a record
 
Similar Threads
NX: Why do you all make LockManagers?
URLyBird question
Beta Question: unlock
B&S Booking and locking
Lock question!