wood burning stoves 2.0*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes Data class Facade and update/delete (lockCookie) Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Android Security Essentials Live Lessons this week in the Android forum!
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "Data class Facade and update/delete (lockCookie)" Watch "Data class Facade and update/delete (lockCookie)" New topic
Author

Data class Facade and update/delete (lockCookie)

Dennis Leong
Greenhorn

Joined: Jul 08, 2009
Posts: 9
Hi all,

I've got a few questions about how to implement the update and delete methods that make use of a lockCookie to verify against your locked map.
In the Facade pattern, as given in the Monkhouse book, every method just passes the call straight through to it's relevant method in the DvdFileAccess or ReservationsManager class. And this works fine as it does not make use of lockCookies, and the general sequence for using update/delete from your middle layer is;



so when update/delete is called, your guaranteed to have the lock of that record (hence the boolean return of Monkhouse lock() method).

With the addition of lockCookie, as far as i can tell, it would make no difference. That is, with a lock(), update/delete and unlock() you should still have the lock of that record in order to update it. Now since you need to throw a SecurityException, you need to do a check against your locked map. To do this, you would need to write code in your Data Facade class such as;



thereby cluttering up your nice Data class.

So i have a few questions about this;
1. Is the lockCookie even relevant, when the application always uses a lock(), update/delete, unlock() sequence of calls, even in a multi-threaded test? is the lockCookie check only needed for unscrupulous updates or out of order lock/unlock calls such as a testing program.
2. Is this the correct approach? is putting such code in your Data Facade update/delete higher level OK? maybe it would be better to just put all the methods in one class and not use a ReservationsManager for lock/unlock in this case.
3. if so, is there still not the possibility that when update() and the checkRecLocked() method is called, another competing thread sneaks in and changes the lock map, so that cookie is no longer valid and is old, thereby giving you incorrect results, as the lower level protection of the map is not available in the Data class.
4. am i way off track here.

many thanks,

cheers,
D
Marko Lugaric
Greenhorn

Joined: May 29, 2011
Posts: 1
Hello.

After long searching on this forum this is the exact problem I have and I have not found any good answer on this matter. Looks like FileAccess class is simply dependent on
ReservationsManager class if you are using Facade pattern.
Roberto Perillo
Bartender

Joined: Dec 28, 2007
Posts: 2258
    
    3

Howdy Dennis (and Marko, welcome to JavaRanch)!!!

1. Is the lockCookie even relevant, when the application always uses a lock(), update/delete, unlock() sequence of calls, even in a multi-threaded test? is the lockCookie check only needed for unscrupulous updates or out of order lock/unlock calls such as a testing program.


Oh, absolutely. It guarantess that the record to be updated was locked by a particular client.

2. Is this the correct approach? is putting such code in your Data Facade update/delete higher level OK? maybe it would be better to just put all the methods in one class and not use a ReservationsManager for lock/unlock in this case.


Well, I too think that this code of your is too smart for a facade. But, since your ReservationsManager and Database classes do not know each other, then the common point is the Data class, and thus this verification has to be done there. It looks more like an Application Service (Core J2EE Pattern) than a Facade (GoF), but I wouldn't say it is a problem.

3. if so, is there still not the possibility that when update() and the checkRecLocked() method is called, another competing thread sneaks in and changes the lock map, so that cookie is no longer valid and is old, thereby giving you incorrect results, as the lower level protection of the map is not available in the Data class.


Well, that will depend on how your synchronization works. If you do it wrongly, then even the lock cookie won't make sense. One option (and I think it is the easiest one) is to synchronize all methods of the Data class. This way, you guarantee that only one client can use it at a time. This way, you can avoid the problem of race conditions you mentioned.


Cheers, Bob "John Lennon" Perillo
SCJP, SCWCD, SCJD, SCBCD - Daileon: A Tool for Enabling Domain Annotations
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Data class Facade and update/delete (lockCookie)
 
Similar Threads
SCJD failed, help needed with locking!
RMI confusion
using LockManager method in DataManager
Confusion over where to call lock methods
double lock + wait logic?