*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes Optimistic vs. Pessimistic Locking Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of OCA/OCP Java SE 7 Programmer I & II Study Guide this week in the OCPJP forum!
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "Optimistic vs. Pessimistic Locking" Watch "Optimistic vs. Pessimistic Locking" New topic
Author

Optimistic vs. Pessimistic Locking

Eric Ellis
Greenhorn

Joined: Nov 01, 2005
Posts: 16
I�ve implemented the first two modules, client and database. I�m now reading up on RMI (O�Reilly, Java RMI � very good book). My database design uses an index (actually two) which allows the search to be run in memory. If I use a versions table to implement an Optimistic Locking mechanism I don�t think there will be a need to implement:

public void lock(int recNo)
public void unlock(int recNo)
public boolean isLocked(int recNo)

It seems as if all I would have to do is synchronize the RandomAccessFile which accesses the .db file and check for version conflicts during updates. This leaves me with a bad feeling in my stomach. It�s way too easy. Please let me know if I�m on to something, or more than likely, have missed the point entirely. Tell me I should be using a distributed event model and Mutexes or something. I�d appreciate anyone�s feedback.

Thanks
Eric Ellis
Greenhorn

Joined: Nov 01, 2005
Posts: 16
I've been reading up on what others have said about locking. It seems that there have been a lot of basic questions (ones that any book could answer) with few concrete answers. I would like to elaborate on my Optimistic locking approach. This pattern is taken from my book Database Access Patterns. I'll try to summarize:

An optimistic lock assumes that an update will be made soon after a record has been selected; as in the case of only having to enter a customer code. A pessimistic lock assumes a record will be held for an extended period of time; as in the case of let's say, news article being edited. In the case of the news article you would want to actually apply a read-only lock. In the case of an Optimistic Lock, you would tag each record with a version (i.e. timestamp). If the record is updated the timestamp is also updated. When a record is selected the timestamp on the client will be compared to the timestamp on the server. A mismatch will update the client�s record. If the record is updated by user A while user B has the record selected, user B upon his update will receive a message prompt to the extent of:

"Another user has updated this record. Would you like to overwrite it?"

I have seen these messages before in many vendor software applications (Microsoft). It seems perfectly acceptable in my eyes but sidesteps the locking implementation of DBMain. My argument for this approach is its simplicity. It seems as if Sun is looking for the straight line approach. As if a real client with a real budget and deadline were paying for this.

My concern is that many of you have completed this assignment and nobody has implemented my approach. Maybe I�m missing the entire point. Sun wants me to prove that I�m capable of implementing a lock manager.

Another point to bring up is that disk reads are inherently synchronized. You don�t want your database cursor looking up a record to lock it, then whisking off to read a record for another thread, only to return to update the locked record. It seems as if all access to the actual binary database file should be synchronized and managed through a Gateway (synchronization pattern). This only makes sense in the context that I have already built an index which is used to search for matching record numbers.

I haven�t worked for a software company for almost five years. I�m all by myself. All I have are my books. Please begin a discussion so that I can modify my design if need be.


Here�s one to ponder�

�The least intelligent people have the greatest margin of error when assessing their own intelligence.�

- Eric Ellis

--- Just a bit of humor ---
Eric Ellis
Greenhorn

Joined: Nov 01, 2005
Posts: 16
For anyone who has traveled this far into my conversation with myself. After looking over the project requirements one more time I�ve come across the following statement:

The following are the �top level� features that must be implemented:

- A client program�
- A data access system that provides record locking and a flexible search mechanism
- A Network server�

�A data access system that provides record locking�
This isn�t saying: �A GUI that provides row locking.�

This is just a safeguard for a race condition. Going back to the DBMain interface; lock() will apply a boolean marker to an array[] (locks table) then proceed to update the version table, then apply for a database (db file) lock to update the record. If another thread is blocked during a lock and then obtains the lock it will find that it�s version doesn�t match and will short circuit displaying a modified version of my previously stated prompt.

�Another user has updated this record. Unable to process your request.�

The second users version will be updated along with the new record data. Of-course both locks will be accompanied by unlock().

The method isLocked() will not be used in this context. This would be similar to calling isActive() on a thread. By the time it returns the state may have changed.


Really the value has been in iterating through my own thoughts in writing. I don�t know why I�ve published this.
Andrew Monkhouse
author and jackaroo
Marshal Commander

Joined: Mar 28, 2003
Posts: 11490
    
  95

Hi Eric,

Welcome to JavaRanch and this forum.

It looks like you've decided to implement the lock() and unlock() methods anyway, but just to add my own comments here...

If I use a versions table to implement an Optimistic Locking mechanism I don’t think there will be a need to implement:

public void lock(int recNo)
public void unlock(int recNo)
public boolean isLocked(int recNo)
Unfortunately leaving these out would violate a must condition in the assignment instructions, namely: 'Your data access class [...] must implement the following interface [...]'. That interface gives specific requirements for what the lock method must do, and being an interface it provides a contract between your Data class and any users of your Data class. Failing to implement the interface could result in automatic failure.

To elaborate: while you have been tasked with developing an end-user system and server (your assignment) another department might have been tasked with writing an application that queries the database, and modifies records matching certain criteria to reduce the price by a certain amount. This other application will assume that the lock() and update() methods will behave according to the interface that the architect provided to both you and them. If you decide to go for a better solution (and yes, in some circumstances, your solution is better) but in so doing you break the interface thereby wasting the other team's time and effort, you will not be popular with your boss!

Regards, Andrew


The Sun Certified Java Developer Exam with J2SE 5: paper version from Amazon, PDF from Apress, Online reference: Books 24x7 Personal blog
Eric Ellis
Greenhorn

Joined: Nov 01, 2005
Posts: 16
Thanks for the reply. I've actually been looking into what I had said about synchronizing the RandomAccessFile. I came across FileChannel. This class throws my whole argument. I'll be multithreading access to the low level IO operations delegating my interface operations to the FileChannel�s locking methods. I�m no expert but I have a book on multithreading (that I read way too fast) which covers Mutexes and Gateways. This seems to be the path I�ll be plotting. Your statement about the interface is going to save my &$# though. I wasn�t planning to implement create() or delete(), event though I�ve written the code for test cases already. Thanks again.
Michael Valentino
Ranch Hand

Joined: Nov 01, 2005
Posts: 96
Careful with FileChannel - this is part of the java.nio package which is not to be used in the development of the project. I thought about using that as well, but my gut told me otherwise for the above reasons.


SCJP 1.4, SCWCD J2EE 1.4, SCJD J2SE 1.5, SCBCD J2EE 1.3, SCDJWS (In Progress)
Eric Ellis
Greenhorn

Joined: Nov 01, 2005
Posts: 16
Hmmm... are you sure? My new design is all ready to go I read a whole bunch of other threads concerning FileChannel in relation to the URLyBird assignment. Nobody else mentioned that it was off limits. Here are two quotes:

Article J2SE 5.0 in a Nutshell
Java 2 Platform Standard Edition (J2SE) 5.0 ("Tiger")


Throughout this exercise, you must use exclusively the Java 2 platform. You may develop your code using any implementation of the Java 2 platform, but the submission that you return must have been tested and shown to work under a production (not development) version of the Sun Microsystems' Java 2 platform and that platform must not have been superseded by a new production version for more than 18 months by the time you make your submission.



This is saying at the least, that it is a requirement that I use version 1.5_x. The nio package came as part of this bundle.

I'd really rather not synchronize my data file if I don't have to. I'll be managing read and write locks on the server both implicitly and explicitly.
Andrew Monkhouse
author and jackaroo
Marshal Commander

Joined: Mar 28, 2003
Posts: 11490
    
  95

Hi Michael & Eric,
Careful with FileChannel - this is part of the java.nio package which is not to be used in the development of the project.
The Sun website says that you may not use NIO, but most (if not all) of the current instructions do not have this restriction. The official word from Sun is that if your instructions do not forbid the use of NIO, then you may use it in your submission.

Regards, Andrew
Eric Ellis
Greenhorn

Joined: Nov 01, 2005
Posts: 16
Thank you again Andrew. I apologize for not reading your book... I feel indebted to you now. I had purchased a different study guide about four years ago when I took the Programmers assignment and am now almost finished; so I'm hard pressed to cough up the money and time to dig into it again. For anyone who's read this far here is a quote from Sun's site:





APIs relevant to the assignment

The assignment generally requires that you can write code using the Java programming language, using any and all constructions. You must also be able to make reasonable use of the following additional facilities and APIs:

* Thread handling and synchronization
* Swing (and AWT to the extent necessary to support Swing)
* Standard file IO (java.io, not java.nio)
* Either: Socket-based network programming and serialization _or_ Java RMI (Java Remote Method Invocation) (your choice of one or the other, not both).

The following APIs and facilities may not be used:

* Enterprise JavaBeans
* Servlets, JSP technology, or any other web-oriented APIs
* NIO, the New IO facilities
* Java DataBase Connectivity (JDBC) and SQL
* Java IDL API and CORBA
* Third party software libraries or tools (such as browsers)


I'm going to be a good little worker bee and follow instructions. :roll:

Really the FileChannel could easily be argued as out of scope being designed for hardware RAID configurations
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Optimistic vs. Pessimistic Locking