aspose file tools*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes The lock bug problem 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 "The lock bug problem" Watch "The lock bug problem" New topic
Author

The lock bug problem

Juan M.
Greenhorn

Joined: Jan 04, 2005
Posts: 6
Hi,

I'm starting the assignment. After reading several posts about people who had a perfect thread locking system and got only 44 out of 80, I noticed that many refer only to RandomAccessFile.

Perhaps this is a naive question but, have you used FileChannel and locks on the file itself (and MappedByteBuffer's for it)? Or just used RandomAccessFile and moved the cursor all over it? If negative, can this lack of file-lock be the problem to the 44 points bug ?

Regards,

- Juan
GD Deepz
Ranch Hand

Joined: Sep 29, 2004
Posts: 55
To be honest, I think people who got bit 44/80 did not take orphan locks into consideration. Is it really beyond the scope of the requirements? I would like to code for orphan locks (i.e lost clients) but my lock method takes a lock cookie. If it did not use a cookie, it will probably be easy to code for orphan locks using WeakHasMap/WeakReference

Have not figured it out yet how the lock cookie can be used for orphan locks. I assume if SUN gave us a cookie to use, then maybe they are not interested in lost clients.
Charles Fung
Greenhorn

Joined: Jan 05, 2005
Posts: 13
I also suspect the 44/80 on locking is due to unhandled orphan lock.

These are the scenarios I can think of, and should be handled:
If a user locks a record and then it crashes, can the server detect it and undo the lock, allowing other user to lock that record? The same user may restart the client and try to lock the same record. Can the server handle it?
Further, if a user locks a record and the server crashes, can the server, on re-start, forget about the previous lock on the record?


SCJD 1.4<br />SCWCD
peter wooster
Ranch Hand

Joined: Jun 13, 2004
Posts: 1033
Originally posted by Charles Fung:
I also suspect the 44/80 on locking is due to unhandled orphan lock.

These are the scenarios I can think of, and should be handled:
If a user locks a record and then it crashes, can the server detect it and undo the lock, allowing other user to lock that record? The same user may restart the client and try to lock the same record. Can the server handle it?
Further, if a user locks a record and the server crashes, can the server, on re-start, forget about the previous lock on the record?


I use RMI for networking and let the network code deal with lost clients. I set the distributed garbage collection lease time to 60 seconds and then use the Unreferenced interface in my DataAdapterImpl class. If the client crashes or unplugs their network connection the DataAdapterImpl will detect the situation in a minute and ask the lock manager to unlock all locks that it owns.
Dieskun Koper
Ranch Hand

Joined: Aug 15, 2004
Posts: 85
I had 44/80 for Locking, and I designed my application not to have orphan locks. I mean, I did all locking on the server side, and paired the lock-unlock calls in try-finally clauses, so no lock would be left locked, even if an error occurs.

I don't see how my locking mechanism could fail with the current requirements, so I suspect it is related to future enhancements.
My delete, create methods were NOPs. If they were to be implemented, my locking mechanism would have to be changed. Also, if they would allow clients to book several rooms in one transaction my locking mechanism would have to be extended. Maybe one point on the accessor's checklist is the extendibility of the locking mechanism?
 
 
subject: The lock bug problem