Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

DB Access Question

 
Ricky Singh
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Guys,

I've recently download my SCJD exam and been going through database section. For my test I've created a write record method for creating, updating or deleting a record. I've also created read record method for reading all record or a record by cretria. i.e.



I've been supplied an interface with the following two methods:


I don't understand where and how I should be using this method, since I use synchronized keyword during my write operation. I don't see the point for any of the methods declared above or am I missing something or missing the point.

Please help....

Thanks

Ricky
 
Jeroen T Wenting
Ranch Hand
Posts: 1847
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The lock methods are to prevent one client from modifying a record that another client is working with.

Say you have 2 clients accessing the database.
Client 1 wants to change the record.
So does client 2.
What happens is that client 1 calls lock and obtains the lock on that record.
Now client 2 will have to wait until client 1 is done with it.
Client 1 can update the record without fear that someone else tries to for example delete it.
Now client 1 releases the lock, and client 2 gets it.
Client 2 can now update the record itself.

The trick is to learn a bit about transactions.
In my solution, I do the following:
- read record.
- make changes in the client application.
- obtain lock.
- reread record.
- compare with the earlier read, if different give an error (something like "concurrent modification") and a chance to back out of the operation.
- modify record.
- unlock record.
- reread dataset (so all records are shown in their latest permutations).

That's an optimistic locking scenario. The entire lock-read-update-unlock operation is done without any user interaction (unless an error is to be reported and acted on by the user).
That means no lock should in practice in my client exist for more than a fraction of a second unless an error occurs.

You can also choose to do:
- lock record.
- read record.
- modify record.
- unlock record.

In this scenario a client could in theory obtain a lock and keep it for ages while it waits for the user to enter some data, go for lunch, change the data, go for dinner at a nice restaurant, meet a lady, run off with her to Hawaii for vacation, get bit by a shark and end up in hospital for a few months, and finally come home and see the application still sitting with that locked record when returning to work the next day.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic