URLyBird Optimistic record locking ?

[steve mcdonald]

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]

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]

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]

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]

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]

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]

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]

> Do you use a Data instace for each client ?

Yes, to pass the client identifier with out changing the the interface DBMain implementation.