aspose file tools*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes Locking Behavior Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login

Win a copy of The Java EE 7 Tutorial Volume 1 or Volume 2 this week in the Java EE forum
or jQuery UI in Action in the JavaScript forum!
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "Locking Behavior" Watch "Locking Behavior" New topic

Locking Behavior

Mike Davis

Joined: Oct 04, 2006
Posts: 3
Hello all,

I just started the Developer Cert, and I'm running into several questions, particularly with the database and record locking.

(I have the home improvement contractor assignment, by the way)

I see a lot of discussion about lockCookies. My assignment says nothing about them, and the method signatures would seem to prevent them. (public void lock(int recNo), etc.)

My main question is, is it safe to assume that my server will be the only client for this database? Without lock cookies, it seems that I would have to trust a thread to only unlock a record that it has currently locked.

Also, if all the locking is done server-side, it seems like it might as well all be done inside the create, update, and delete methods, rather than forcing the client to lock-modify-unlock.

If the lock is done inside the writing method, however, that means that a database client (still server-side) trying to do lock-modify-unlock, would create a deadlock.

So, the big question: If the GUI client cannot cause deadlock, and the exposed server methods cannot cause deadlock, am I safe, even though directly calling certain database methods could cause deadlock?

Bhavik Patel
Ranch Hand

Joined: Jul 12, 2004
Posts: 155
My main question is, is it safe to assume that my server will be the only client for this database? Without lock cookies, it seems that I would have to trust a thread to only unlock a record that it has currently locked

I guess you are trying to say is your server serves one client at a time...
ifyour method doesn't inclcude cookie signature is oneway of good sign you have broad choices for choosing cookie...I have long cookie in method for lock i am bound to provide long cookie...Do you know why cookie is required??Its main purpose is to improve performance and less reliable synchronized your sequence goes like

in the lock you generate a cookie and check if this cookie is in the
collection or not if so then you have to wait until its removed ..and once you got a chance ,you can put that cookie in collection and perform your update and in unlock you remove the cookie from collection .This way you can make sure at a time one client is updating ..Without Client identification (cookie stuff) how do you make sure this ??Hope this will help you ..and about lock call at client or server is like fat server or fat client issuse and your decision ...Either way is good..according to my methods i am forced to that calls at client side...Hope it helps...

SCJP 1.4<br />SCWCD 1.4(91%)<br />Working on SCJD -Bodgitt & Scrapper Constructions...<br /> <br />"It takes 43 muscles to frown & 17 to smile but it doen't take any to just sit there with a dumb look on your face .. Keep Smiling "
Mike Davis

Joined: Oct 04, 2006
Posts: 3
The description says I need to be able to support multiple simultaneous clients. My question is, do I know that every client accessing my server will be an instance of the client I wrote?

Based on the problem description, there's no need for clients to be able to lock records. The specified interface seems to prevent lock cookies, so is it possible that all locking should be done on the server side?

Anthony Bull

Joined: Nov 08, 2004
Posts: 8
There is no need for your client to be calling lock or unlock. A call from the client to update a record should be atomic, not islocked->lock->update->unlock. Your server should be handling the details of locking. This is additionally good because it is way simpler to code.

Imagine it in the real world - you have a client that says - update this instance, and the server handles starting a transaction, locking the record, running the SQL then committing the transaction. You would never require your client program to know about transactions.

Its a pretty poor design to assume your client will handle locking/unlocking a record, because you can never guarantee that a client will implement it correctly. E.g. eBay would not rely on people writing third party clients to correctly handle locking their database!
Allan Jacobs

Joined: Aug 28, 2006
Posts: 15
I'm working on the same problem. There is one interface
specified for use in the server and it's a "data access interface."
The interface mandates lock, unlock, and isLocked method calls.

About lock cookies, there was another post about the
the home improvement contractor assignment. It was
noted that the data access interface did not specify RemoteException.
For instance,
public void lock(int recNo) throws RecordNotFoundException;
The reply in that post hinted that it might be the case that the
"data access interface" is different from the interface that a
client sees. Solutions might be free to use more than one
interface as long as one of them is from the assignment.

The assignent says that "must provide locking functionality as
specified in the interface provided." If we interpret the words
"data access interface" from the assignment instructions as
applying to the server only some of the problems go away.

This leads to the next befuddlement. It's possible to solve the problem
by implementing but not actually using the lock/unlock/isLocked
interface -- synchronization statements alone are sufficient.

My take on this is that synchronization should be avoided. One
benefit of implementing and using the lock/unlock/isLocked system
is that you can build in timeouts. That would allow the application
to cope with client crashes.

Another problem: the application has to be able to lock records
before it deletes them. The assignment instructions also say
that unlock method call throws an exception when called upon to
remove the lock from a deleted record. The assignment instructions
do not say whether or not the lock is actually removed in this
case. This is probably yet another reason to hide the unlock
method from client programs. Yuck.
I agree. Here's the link:
subject: Locking Behavior