• 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 Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Tim Cooke
  • paul wheaton
  • Jeanne Boyarsky
  • Ron McLeod
Sheriffs:
  • Paul Clapham
  • Liutauras Vilda
  • Devaka Cooray
Saloon Keepers:
  • Tim Holloway
  • Roland Mueller
Bartenders:

DB Access Question

 
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
 
Ranch Hand
Posts: 1847
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.
 
You are HERE! The other map is obviously wrong. Better confirm with this tiny ad:
We need your help - Coderanch server fundraiser
https://coderanch.com/wiki/782867/Coderanch-server-fundraiser
reply
    Bookmark Topic Watch Topic
  • New Topic