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

Static HashSet problem

Jo Fail
Greenhorn

Joined: Feb 05, 2003
Posts: 18
Dear All,
This is my first posting on this forum and I'm afraid that it is a pretty dumb question! Sorry!
I am trying to code up the lock and unlock methods in the data class. Currently I have defined a variable thus
private static HashSet locks = new HashSet();

to keep track of locked records.
My understanding is that a static variable exists only once for a class - but this does not appear to be the case when I try and test it.
To test it I set a breakpoint in my lock class and watched it add() the selected record number into locks and then left that session hanging. I then start up a second window and attempt to update the same record - when I debug this time the locks variable has a different id to that from the one for the first window and is empty so it lets me go ahead and update.
I guess that I am missing something pretty fundamental here - can anyone tell me what it is?
Mark Spritzler
ranger
Sheriff

Joined: Feb 05, 2001
Posts: 17249
    
    6

It is not a stupid question.
But, why have it static? You are only ever going to create one instance of the Data class.

This was my line in my Data class.
And you might also want to do a search on the LockManager object. This is a very good approach at locking that many have used.
Mark


Perfect World Programming, LLC - Two Laptop Bag - Tube Organizer
How to Ask Questions the Smart Way FAQ
Brian Blignaut
Ranch Hand

Joined: Jan 08, 2003
Posts: 61
How are you connecting to the lock manager? Are both of your clients running in the same VM as the Lock manager?
Remember there is only one instance per class per VM. So if you are running each client in it's own VM and not connecting to the same lock manager/server then you are not dealing with the same instance of the Lock manager. Hence the reason your Set is empty.
Jo Fail
Greenhorn

Joined: Feb 05, 2003
Posts: 18
That's a very good point Brian - I think that you must have hit upon my problem and clearly I can't rely on all instances being in the same VM. Thanks for that.
Also thanks to Mark - I have read lots and lots on the lock/unlock subject in this forum but I can see that I need to go over it again. It seems like a fairly simple subject but it's a can of worms!
Brian Blignaut
Ranch Hand

Joined: Jan 08, 2003
Posts: 61
Well I actually think you can really on it being in the same VM. The reason I say this is that, as far as I am concerned, the only time you actually need to use your lock manager, is when you are connecting to the remote server, as locking in local mode is implied (database and client run in the same VM, so only one client can be connected to one database at any given time, so no chance of someone else unlocking your row). Therefore you will only have one instance of your lock manager and all lock requests will go through that instance.
Question : If you are using a set how are you going to store who locked the record?
Jo Fail
Greenhorn

Joined: Feb 05, 2003
Posts: 18
Brian
My understanding about VMs is pretty limited - another thing to read up on.
"Question : If you are using a set how are you going to store who locked the record?"
Last night when I posted my question I was feeling that storing a reference to who locked the record would be over complicating the issue. Now I'm not so sure.
My requirements state "However, if two clients attempt to perform the sequence lock, read, modify, write and unlock concurrently, then both modification attempts will be handled correctly"
That to me implies that I do not have to police the lock/unlock as intenesely as to include a client identifier and can just rely on the applications behaving resonably and not attempting to unlock somebody else's lock. Would you not agree?
Jo Fail
Greenhorn

Joined: Feb 05, 2003
Posts: 18
Mark, you said
"But, why have it static? You are only ever going to create one instance of the Data class."
That's really thrown me - Yes I am only going to create one instance of the Data class for one GUI window but where there are multiple clients then I will have multiple Datas - won't I? And it is the concept of multiple clients that I am coding all the lock /unlock for?
I must be missing something again?
Mark Spritzler
ranger
Sheriff

Joined: Feb 05, 2001
Posts: 17249
    
    6

Coding for multiple clients is in remote mode, so the one instance of Data will only exist on the server, so each client won't have a new instance of Data.
In local mode there is only one client and no use for locking.
Mark
Brian Blignaut
Ranch Hand

Joined: Jan 08, 2003
Posts: 61
Hi,
Where you state that you don't need to police the locks, I disagree, my spec also states that only the person that locked the record can unlock it, which means that you have to keep a record of who locked the record
Peter den Haan
author
Ranch Hand

Joined: Apr 20, 2000
Posts: 3252
Check the javadoc for Data.unlock() and take it from there.
- Peter
Jo Fail
Greenhorn

Joined: Feb 05, 2003
Posts: 18
Thanks guys.
Yes I see now that further down in the spec it says "If an attempt is made to unlock a record that has not been locked by this connection , then no action is be taken" (sic)
Also thanks to Mark re the "one instance of data" - I have yet to code my RMI stuff it will all be new to me - knowing this will set me off on the right track.
[ February 07, 2003: Message edited by: Jo Fail ]
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
 
subject: Static HashSet problem
 
Similar Threads
hi Mark! need your opinion. "lock()"
Tests for the Data class/locking mechanism
delete in B&S
B&S: Locking Question
Concurrency problem in URLyBird