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 B&S Is it OK To Generate The long Value For The Lock in Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of EJB 3 in Action this week in the EJB and other Java EE Technologies forum!
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "B&S Is it OK To Generate The long Value For The Lock in "lockRecord()" Randomly?" Watch "B&S Is it OK To Generate The long Value For The Lock in "lockRecord()" Randomly?" New topic
Author

B&S Is it OK To Generate The long Value For The Lock in "lockRecord()" Randomly?

Bob Nedwor
hangman
Ranch Hand

Joined: Aug 17, 2005
Posts: 215

On page 151 of Andrews book, he hints at the possibility of generating the locks randomly, but I can't find where it definitely says this is acceptable or not. How are the rest of you determining what to return when the lockRecord() method is used? Thanks so much for any hints...


Bob N
SCJP - 1.4
SCJD - (B&S) Used 1.5 And It Runs On Solaris10
SCWCD - Thanks to HFSJ!!
Bob Nedwor
hangman
Ranch Hand

Joined: Aug 17, 2005
Posts: 215

Looks like I just found it. This topic seems to mean that this is pretty much the way to do it:

topic
Dan Burke
Greenhorn

Joined: Feb 27, 2006
Posts: 10
I used this approach. I would bet money against the possibility of a call to Random.NextLog returning duplicate locks..its possible but extremely improbable.
Eiji Seki
Ranch Hand

Joined: Feb 15, 2006
Posts: 88
I intend on using it, but just in case I will kind of keep track of used longs so I guarantee there will be no duplicates.


SCJD URLyBird (WIP)<br />SCJP 1.5
Bob Nedwor
hangman
Ranch Hand

Joined: Aug 17, 2005
Posts: 215

Thanks, Eiji. Excellent point.
Lara McCarver
Ranch Hand

Joined: Dec 09, 2003
Posts: 118
Why would you use Random, then keep track of what has been used... this really sounds like a lot of work. Couldn't you have a static int in your LockManager class which incremented in the LockRecord() method, and handed back in a thread-safe way? (I didn't use locking cookies in my assignment, so I could be way off base here.)

Lara
Eiji Seki
Ranch Hand

Joined: Feb 15, 2006
Posts: 88
Yes, you could do that also.

The random solution, on the other hand, is more complete, since it is safer. It is a real life solution, so it is not mandatory (the increment is enough), but since it is not that difficult to do, I see no problem.

Just imagine if your web server used an incremental session ID instead of a random one. If you just saw your session ID is 1234, you could probably use 1233 and get a valid session, luckly with credit card information or other confidential information already inputed.

Also if you want to increase performance, the random solution allows you to generate id's without synchronization. Off course, having the possiblity of collision (larger or smalled depending on keeping tracks or not).
Yupp Cook
Ranch Hand

Joined: Feb 07, 2006
Posts: 49
Originally posted by Lara McCarver:
Why would you use Random, then keep track of what has been used... this really sounds like a lot of work. Couldn't you have a static int in your LockManager class which incremented in the LockRecord() method, and handed back in a thread-safe way? (I didn't use locking cookies in my assignment, so I could be way off base here.)

Lara


Hi Lara
Here's a solution of generating it randomly using the full long range without lot of work

Long value;
Map lockedRecs;
do {
long lRandom = (long)((Math.random() * 2 -1) * Long.MAX_VALUE);
value = new Long(lRandom);
}
while(lockedRecs.containsValue(value));

Yupp


SCJP 1.4<br />SCJD (BS2.1.2)
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: B&S Is it OK To Generate The long Value For The Lock in "lockRecord()" Randomly?
 
Similar Threads
Just Passed SCJP
ORB Outgoint socket port
Interview Experience - Logical Test
Cookie value used in DBAccess Interface
Part II: Integratting the Application Client with the legacy CGI interface