Johnny Hastings

Greenhorn
+ Follow
since Mar 09, 2006
Merit badge: grant badges
For More
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Johnny Hastings

Thanks for the responses fellas. I guess I should have been a bit more descriptive in my original post.

The DB.java interface I received from Sun does indeed have the lock method returning a type long, not void.

To say a bit more about my locking strategy:
I have a class which implements the provided DB.java interface, called Data.java (just as Sun described in the assignment). That class has a data member which is an instance of the singleton class LockHandler.java. LockHandler is supposed to control all of my locking. LockHandler cares nothing about records or data, just locks. Data.java generates the lock cookies through a synchronized method. It also keeps track of which lock cookies are in use (via an array), and will not use the same lock cookie twice.
I planned on not having clients hold a lock for any time, other than the brief moment of update. If a client wants to update a record, they make their changes, then when it's time to save, the data is sent to the server. @ that point, the database is updated. If an update is currently in process on the current record, then the user waits. This does create the issue of stale data. While one user is working with a Should I reconsider this approach? It seemed like it would satisfy the requirements as long as the proper messages were passed back to the user in case they were trying to book an already booked record. Thoughts on this subjust (as well as on the locking strategy above) are greatly appreciated.
Alright, I've been through this code 100 times, and I think I have it. Can anyone take a look and tell me if they see any holes in it? I will do a thorough test once I get the Data.java class finished, but it would nice to have a heads-up in case something didn't look kewl. Any thoughts or ideas are appreciated!

From Data.java (specified by Sun in the assignment)


From LockHandler.java. Singleton class I implemented to take care of locks.
Congrats! I too would be interested in a brief summary of the locking strategy you used.
17 years ago
Greetings all. I've been reading over several other posts around here on this subject, and I thought I'd go ahead and make one of my own. Below is pseudocode for my B&S locking strategy. I've been looking/thinking over this for a week and a half now, and have probably changed it well over 100 times. The first method below is from my data.java file, as spec'ed by Sun, and the others are from my lockhandler class. Does anyone see any obvious holes in this? Does it seem like it will fulfill the objective? I'm new to this threads thing, being mostly a web developer, these are problems I usually let the servlets handle!

[ May 10, 2006: Message edited by: Johnny Hastings ]
I hadled this issue by caching the data in the application. All interactions that the users have with the data is actually with the application cache of the data, not the file itself. When I read in the records, into a Vector, the order in which they get added becomes their key. Occasionally I write them back out to the file (when needed do to changes by the users), and it doesn't matter what order they end up in as/when they go out.

This is my first post here too, but I hope that helps you some.