This week's giveaway is in the Android forum.
We're giving away four copies of Android Security Essentials Live Lessons and have Godfrey Nolan on-line!
See this thread for details.
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes URLyBird Optimistic record locking ? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Android Security Essentials Live Lessons this week in the Android forum!
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "URLyBird Optimistic record locking ?" Watch "URLyBird Optimistic record locking ?" New topic
Author

URLyBird Optimistic record locking ?

steve mcdonald
Ranch Hand

Joined: Nov 18, 2005
Posts: 46
Well, any one implemented Optimistic record locking ?

i am thinking, i will do as less as possible that satisfy requirements.

1. prevent rebooking of the same room if it is already booked by some other user while this user was in the thinking process. Application displays a good user friendly message when this situation arises.

2. also means that i will be only checking the owner attribute for null or empty string (for booked status detection) before updating the record.

3. I don't allow any changes from the GUI to any other attributes other than owner column. Because the UI requirements are only to provide flexible searching capabilities and book rooms for selected records/owner.

An i on the right track ?


There may be changes to the records with out booking ? All other changes apart from booking, Who ever did the last change wins.
Pawel Poltorak
Ranch Hand

Joined: Sep 21, 2005
Posts: 36
Hi Steve,

I was thinking about similar way to perform booking. From assignment I assume that updating records is done by some external software, so I think it's safe as long as it's explained in choices.txt. But I may be wrong, so let more experienced ranchers give us their opinion .

I saw threads where people explained, that they compare values from gui with those from server and if they're different they show message.

Regards,
Pawel


SCJP, SCJD
Andrew Monkhouse
author and jackaroo
Marshal Commander

Joined: Mar 28, 2003
Posts: 11404
    
  81

Hi Steve,

I think optimistic locking is the most common way of handling booking that I have seen discussed here.

Your other assumptions look fine to me (but dont forget to write up your assumptions in your choices document ).

Regards, Andrew


The Sun Certified Java Developer Exam with J2SE 5: paper version from Amazon, PDF from Apress, Online reference: Books 24x7 Personal blog
steve mcdonald
Ranch Hand

Joined: Nov 18, 2005
Posts: 46
Hi Pawal and Andrew,
thanks for the replies.


> I saw threads where people explained, that they compare values
> from gui with those from server and if they're different they show message.

Well (IMHO) i think this is a bad idea, because while the gui is re-reading and re-checking again before booking, one other user may have updated already, so it is best to perform at the database layer, with the optimistic locking, if necessary double-checking mechanizm after obtaining the lock on lockedrecords datastructure.
Andrew Monkhouse
author and jackaroo
Marshal Commander

Joined: Mar 28, 2003
Posts: 11404
    
  81

Hi Steve,

What do you mean by "at the database layer"? Are you talking about the Data class itself or are you talking about the business layer (which may be at the server level or may be at the client)?

My personal opinion is that it would be a mistake to have business logic (confirming that the record is still available to be booked) in the Data class itself. The Data class is a generic class for accessing data - there is nothing in it that is specific to the type of records contained in a file. If you put business logic in there then you will make the Data class specific to your type of file.

If you put the business logic in any higher layer then you are going to have to read the record to verify that it has not been booked. If you are putting your business logic on the server then you could have a bookRooms() method (or similar) that is synchronized that does the availability check, however this means that only one client can book a room at any given time - greatly reducing concurrency. It also means that you will be performing many operations within the synchronized block that really don't need to be synchronized.

Alternatively, no matter whether the business logic is on the server or on the client, you could have your bookRoom() method use the calls to lock() and unlock() to keep others away from that particular record.

Regards, Andrew
steve mcdonald
Ranch Hand

Joined: Nov 18, 2005
Posts: 46
Andrew,

Actually i meant the Application layer, sorry i typed as Database layer

My design has the following :

1. GUI uses BusinessDelegate for application facade services

2. BusinessDelegate - Shields GUI from where services are implemented,
like a facade and serves GUI. This essentially provides GUI with rich coarse grained functional services using AppServer Services

3. ServiceLocator - used by BusinessDelegate to locate Local or Remote implementation, under the covers, based on the mode, that implements BusinessServiceInterface

Note.: BusinessServiceInterface is what i defined that are basic coarse grained services that GUI definetly need. BusinessDelegate may develop more higher level services based on these basic services

4. ServiceLocator - locates Local or Remote service based on the mode of startup

5. BusinessServiceImpl - Actual implementation of AppServer side Business logic that implements BusinessServicesInterface. (currently this works in the same JVM as the data access classes, no middle tier, but will support if needed.)

6. BusinessServiceImpl uses Data class (that implements DBMain interface)

7. Data Class uses DataFileHandler class. DataFileHandler class is actually a handle to the specified datafile that is responsible for Navigation of the filepointer and reading and writing bytes (raw data) in and out to the file. Also has enough synchronization to provide concurrent access and protect data integrity. Because i am just using one fileHandle/FilePointer to navigate and perform specified actions.

8. Data class uses Lock Manager handling the logic to lock unlock, clearing stale locks.
Mihai Radulescu
Ranch Hand

Joined: Sep 18, 2003
Posts: 916

Hi Steve,

As I userstand your workflow is :
Client -> BusinessDelegate -> ServiceLocator -> BusinessServiceImpl -> Data -> DataFileHandler.

Looks reasonable to me.

Do you use a Data instace for each client ?

Regards,
Mihai


SCJP, SCJD, SCWCD, OCPJBCD
steve mcdonald
Ranch Hand

Joined: Nov 18, 2005
Posts: 46
> Do you use a Data instace for each client ?

Yes, to pass the client identifier with out changing the the interface DBMain implementation.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: URLyBird Optimistic record locking ?
 
Similar Threads
Should lock methods be callable by the client
NX: Does this mean I MUST use multiple DB instances?
NX:Locking - one data instance or multiple
Passed SCJD with 390 / 400 (97,5%)
Can I use another db file for optimistic locking?