• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

URLyBird Optimistic record locking ?

 
steve mcdonald
Ranch Hand
Posts: 46
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 36
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
Andrew Monkhouse
author and jackaroo
Marshal Commander
Pie
Posts: 11866
194
C++ Firefox Browser IntelliJ IDE Java Mac Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
steve mcdonald
Ranch Hand
Posts: 46
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Pie
Posts: 11866
194
C++ Firefox Browser IntelliJ IDE Java Mac Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 46
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 918
IntelliJ IDE Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
steve mcdonald
Ranch Hand
Posts: 46
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
> Do you use a Data instace for each client ?

Yes, to pass the client identifier with out changing the the interface DBMain implementation.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic