Win a copy of Learn Spring Security (video course) this week in the Spring forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

lock and synchronized method

 
Yuan Ye
Ranch Hand
Posts: 172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 18671
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Yuan Ye
Ranch Hand
Posts: 172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 18671
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic