File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes lock and synchronized method Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "lock and synchronized method" Watch "lock and synchronized method" New topic
Author

lock and synchronized method

Yuan Ye
Ranch Hand

Joined: Mar 05, 2003
Posts: 172
Hi, guys. I have studyed Max's example of db access model. He used a single DBAdapter for all remote clients. The DBAdapter will lock a record and then call a methed in DVDDatabase. All methods in the DVDDatabase are synchronized. It seems to the locking + synchronized method is redundent. To me, since only one method in the DVDDatabase can be called at a time, there would not be a mutliple data access issue, thus locking is not necessary. I don't know where I missed, but I really think either synchronized method or locking will be enough for this single instance case. Thanks.
Jim Yingst
Wanderer
Sheriff

Joined: Jan 30, 2000
Posts: 18671
Why do you say only one method can be called at a time? As you point out, Max uses a single DVDAdapter on the server side, to handle all connected clients. What's going to prevent two remote clients from trying to call methods at the same time? The DVDAdapter has to handle this somehow - it passes the responsibility on to the contained DVDDatabase instance, which in turn handles the problem by synchronizing. Now no two synchronized methods can execute simultaneously.


"I'm not back." - Bill Harding, Twister
Yuan Ye
Ranch Hand

Joined: Mar 05, 2003
Posts: 172
Yes. I agree, if two clients want to to access the data, synchronized method will prevent it happening. And I also think synchronized method can prevent two clients accessing a same record, so synchronized method along is enough for this case. What is record locking used for then? Where am I wrong? Thanks.
[ September 30, 2003: Message edited by: Peter Ye ]
Jim Yingst
Wanderer
Sheriff

Joined: Jan 30, 2000
Posts: 18671
Well, I'm not entirely sure when/if it's really necessary in Max's code. I think that the methods he implements are all simple enough that he probably could have gotten by with sync only, no locking. (However it's very possible I've overlooked somethign; I just quickly scanned DVDDatabas and DVDDbAdapter.) But where locking could come in useful is if you want to build more complex operations out of several consicutive DVDDatabase methods, and need to ensure that the records you're dealing with remain unchanged while you're working with them. In the NX assignments for example, we've been assigned to implement a DB interface with rather low-level methods, and for some things we need to do later, we can't accomplish them all in one method call. So for example, in order to rook a record, we need to do something like
1. read record to see if it's already booked by someone else
2. if OK, book the record by writing to DB.
Here, this requires two separate method calls in the DB interface - one read, and one write. We need to ensure that no modification to the record occurs in between these two calls. It's harder to use synchronization to protect you across multiple method calls; you'd need to create a new method which makes the multiple calls, and sycn that new method, but theyn you're getting into nested sync locks, and there are a lot of ways this can run into deadlock troouble if you're not careful. And we don't really want to add public methods to the DB class; we'd rather put them in a separate Adapter class, except then the synchronization is split across two diffferent classes, and becomes harder to debug. And every time you want to add new high-level methods to the adapeter, you've got to put in more new synchronized code, which leads to more potential issues... Using locking is a relatively simple and extensible way of ensuring that any time a coder wants to modify data, they first make sure they have exclusive access to it. A junior programmer might accidentally forget to synchronize somethign, and it won't be immediately obvious. But if they accidentally forget to lock something before they update, they'll get a nice obvious SecurityException which forces them to fix their mistake right away. So this can helpwith debugging and maintenance later.
Again, I'm not really talking about Max's code here, I'm talking about the NX assignments. Max had more freedom to design his assignment they way he wanted; I'm not sure there is a compelling need for locking in his design other than to be similar to the actual assignments. But again, I could well be missing something here.
Note that for the actual NX assignments, the other compelling reason to use locking is "because Sun told us to". We're required to use locking, period, and we also need sync for the reasons I described earlier.
Yuan Ye
Ranch Hand

Joined: Mar 05, 2003
Posts: 172
Jim, You are exactly right. If there are more than one steps in a method involving the DBAccess, locking is a must. Now everything is much clear to me. Thanks a lot.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: lock and synchronized method