• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

uestion about General locking mechanism

 
Ray Robinson
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello

Appreciate if people help me out with their opinion:

My questions may be already answered in bits and pieces somewhere.I am trying to verify my understanding about locks and threading (I am yet to download my project). Is the following advisable? Am I missing something?

================== Plan ===================
Maintain a collection data structure which holds the records locked and owner info. I call it "lockList" hereafter

Query:
Read the data file record by record, if matches search criteria AND not in the lockList OR in the lockList with user himself as owner
then =>return record(s)


Update Record(s):
If user has record(s) cached (e.g. in GUI) , find the corresponding record(s) in data file, if in lockList by some other owner => Issue message/exception.... Also if not in lockList by some other owner, but record data is not exactly same (or deleted) => issue message/ some exception

Add Record(s):
User verify record is not existing (not even in lockList) and add the record.

General policy for read or write is to lock the record (put in lockList with owner info) and work (read/write) on the record. And unlock.

If no exceptions .eg. Out of Sync, wait for max X sec and return with message/exception.


So this was my conception about a simple implementation(probably from 30000ft high ).

Is it worth?
Also should there be a record identifier for searching? Does spec allow one ?


Appreciate feedback.

Regards
Ray
 
Andrew Monkhouse
author and jackaroo
Marshal Commander
Pie
Posts: 12014
220
C++ Firefox Browser IntelliJ IDE Java Mac Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Ray,

Welcome to JavaRanch and this forum.

Why don't you want to return a record from a query if there is a lock on it?

I think your logic checking lock ownership for your update may be expressed incorrectly. The way I am reading your overview, a client could perform an update without gaining a lock.

Why do you want to lock a record before performing a read? (I suppose a more important question is: are you talking about logical locking (using the lock() method) or are you talking locking access to the entire data file (synchronized block around file access?)

I don't understand what you mean by:
If no exceptions .eg. Out of Sync, wait for max X sec and return with message/exception.
Regards, Andrew
 
Ray Robinson
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Andrew

Thanks Andrew. I am a newbee, I like the forum.
#1
By locking, I mean logical locking. Each object in the list(which I call lockList) represents a record which is locked by some user. The access methods for the lockList is synchronized.

#2
I thought if a record is locked, it signifies the record data might be undergoing change, so better not to return the record in query.


#3
If no exceptions .eg. Out of Sync, wait for max X sec and return with message/exception.

... I mean, suppose a thread(user) is willing to update a record( he has the data cached in GUI from previous query)..While trying to get the logical lock of the record( must have lock for update) , if user finds it is already locked by someone else, then wait for X sec(timeout).

OR If user gets the lock on the record, but finds his cached data is not matching with actual file data( i.e someone was there in between), then throw OutOfSync exception and abort the update and unlock.


Appreciate opinion.

-Ray
 
Andrew Monkhouse
author and jackaroo
Marshal Commander
Pie
Posts: 12014
220
C++ Firefox Browser IntelliJ IDE Java Mac Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Ray
I thought if a record is locked, it signifies the record data might be undergoing change, so better not to return the record in query.
Hypothetically, if a user locks a record, then later unlocks it without making a modification, then you restricted the second user from seeing the record for little gain. I am not necessarily saying you are wrong, just playing devil's advocate here .

Also - say client A reads record 2. Client B then locks record 2. Client C now tries to read record 2. According to your logic, client C cannot see a record that client A has on their screen - even though it is not yet booked.
... I mean, suppose a thread(user) is willing to update a record( he has the data cached in GUI from previous query)..While trying to get the logical lock of the record( must have lock for update) , if user finds it is already locked by someone else, then wait for X sec(timeout).
Hmmm. Do the comments in your provided interface make it appear that the lock method can timeout?
OR If user gets the lock on the record, but finds his cached data is not matching with actual file data( i.e someone was there in between), then throw OutOfSync exception and abort the update and unlock.
Why would this be an OR statement? Consider client A loading the record from the database. Client B locking - booking - unlocking the record. Then client A tries to book the record. Regardless of whether locks could time out or not you still have to ensure that client A does not overwrite client B's booking.

Regards, Andrew
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic