aspose file tools*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes Locking strategy Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "Locking strategy" Watch "Locking strategy" New topic
Author

Locking strategy

Daniel Travin
Greenhorn

Joined: Oct 19, 2007
Posts: 7
Hi all,

I am wondering about the 100% scoring locking strategy.

My own view on this problem is clear and simple
* Methods that perform operations with I/O are synchronized
* There is a HashMap "lockedRecords" with key=recNo and value=Lock in the file
* Implementation of DBAccess is trying to acquire the lock on the record using this code



* Implementation of DBAccess is trying to release the lock with the following



* There is a thread that is searching for timed out locks and releasing them


* After acquiring lock the instance of acquired lock is synchronized and at the end of the synchronized block the lock is released

As far as I know this is not a good solution.
Can someone tell me why?

[ November 13, 2007: Message edited by: Daniel Travin ]
[ November 13, 2007: Message edited by: Daniel Travin ]
Alex Belisle Turcot
Ranch Hand

Joined: Apr 26, 2005
Posts: 516
Hi,

I'm not sure I understand the question..

However, I will say this, just to point it out, to pass on the information. I'm a bit scared of using the iterator on my HashMap for this assignment..

HashMap (Java 2 Platform SE 5.0)


The iterators returned by all of this class's "collection view methods" are fail-fast: if the map is structurally modified at any time after the iterator is created, in any way except through the iterator's own remove or add methods, the iterator will throw a ConcurrentModificationException. Thus, in the face of concurrent modification, the iterator fails quickly and cleanly, rather than risking arbitrary, non-deterministic behavior at an undetermined time in the future.

Note that the fail-fast behavior of an iterator cannot be guaranteed as it is, generally speaking, impossible to make any hard guarantees in the presence of unsynchronized concurrent modification. Fail-fast iterators throw ConcurrentModificationException on a best-effort basis. Therefore, it would be wrong to write a program that depended on this exception for its correctness: the fail-fast behavior of iterators should be used only to detect bugs.


Regards,
Alex
Daniel Travin
Greenhorn

Joined: Oct 19, 2007
Posts: 7
Yes, I agree that HashMap is not good data structure for this kind of task.

My question was about what objects to synchronize and how to synchronize inside the implementation of DBAccess methods.

I have read through this forum and I see that some people get 80/80 marks for locking and some of them get 44/80.
That 's why I am asking for what locking strategy is the best from the Sun testers point of view.
Alex Belisle Turcot
Ranch Hand

Joined: Apr 26, 2005
Posts: 516
Hi,

I use an HashMap to hold informations on records that are locked.
Manipulations done on my HashMap object are inside a synchronized block.

I would think you should be very advanced into your lock / unlock strategy before you worry too much about 80 or 44.. It is still unclear the cause for that..

I've read it could be caused by the exception thrown. Or the application is being accessed by clients from multiple platforms. Or SUN is using special "mean bad ass sent by aliens" test case. Or thread are using CPU cycle. Or unnecessary use of Notify/notifyall from your lock method. Or update/delete not making sure the record is locked. Or record can be unlocked by any thread (not just the owner). Or...

I think there is a long period of thinking and designing before worrying about the 80 or 44 scoring issue.

Well at least, that's how it works for me

regards,
Alex
[ November 13, 2007: Message edited by: Alex Belisle Turcot ]
Alex Belisle Turcot
Ranch Hand

Joined: Apr 26, 2005
Posts: 516
re-Hi,

If you want to identify your client from your lock object (HashMap), then some unique information on your client should be your value in your HashMap. I think that is what most people are using...

As for synchronizing on all I/O methods, remember that read operation must be able to perform concurrently no matter which records they access.

You can then choose, when a write operation is performed, to lock and forbid other write operations on it and/(or-not) also read operation on it.

If you read posts the ranch, you'll see that most people choose to ignore (in their lock/unlock strategy) the possibility that a read operation occurs during a write on the same record.

I do that.. Read operations don't need a lock, it's free for all. I'm not so gentle with write operations and they need to get permission.

Regards,
Alex
[ November 13, 2007: Message edited by: Alex Belisle Turcot ]
Chris Hurst
Ranch Hand

Joined: Oct 26, 2003
Posts: 416
    
    2

I do that.. Read operations don't need a lock, it's free for all.


As long as your sure there is a memory barrier of course, just thought I better mention that in case any threading newbie's take it the wrong way. There are can be a lot of gotcha's round removing locks on reads, though it can be done ...


"Eagles may soar but weasels don't get sucked into jet engines" SCJP 1.6, SCWCD 1.4, SCJD 1.5,SCBCD 5
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Locking strategy