• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
  • Campbell Ritchie
  • Bear Bibeault
  • Ron McLeod
  • Jeanne Boyarsky
  • Paul Clapham
  • Tim Cooke
  • Liutauras Vilda
  • Junilu Lacar
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • fred rosenberger
  • salvin francis
  • Piet Souris
  • Frits Walraven
  • Carey Brown

DB Access Question

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....


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.
Eat that pie! EAT IT! Now read this tiny ad. READ IT!
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop
    Bookmark Topic Watch Topic
  • New Topic