Static HashSet problem

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?

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

posted Feb 06, 2003 07:44:00

0

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

posted Feb 06, 2003 07:54:00

0

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

posted Feb 06, 2003 08:09:00

0

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

posted Feb 06, 2003 09:57:00

0

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?

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

posted Feb 07, 2003 00:13:00

0

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

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 ]