How to Lock(-1)

[Sam Stackly]

Hi Guys,
Can anyone one give me a hint about how to implement Lock(-1)?
Thanks in advance
Sam

[Max Habibi]

Sam,
Here are some things to think about: once you clear these up, your coding should be easier.
If the db already contains locks on record(s), then are you going to wait until those locks are removed, or are you going to lock it right away?
Are you going to stop accepting lock requests once a lock(-1) record comes in, or are you going to process them normally?
Are you going to lock records before reading? If so, how are you going to handle read requests when the entire db is locked?
Otherwise, you should treat locking the entire db just like locking any other record.
HTH,
M, author
The Sun Certified Java Developer Exam with J2SE 1.4
[ July 24, 2002: Message edited by: Max Habibi ]

[Sam Stackly]

Thanks Max,
I assume that Lock(-1) is just for server clean up and shutdown, so all I need to do is implement lock(-1) in server side when in ServerGUI , administrator decide to shut down server ,(am I right?)
Thanks
Sam

[Max Habibi]

Not Necessarily: for example, you might decide to lock the entire db before performing certain kinds of reads. Why? Because otherwise, one thread might be reading data while another is updating it: in effect, you'll get a dirty read. Now, this might be ok, and it might not, depending on the rest of your design.
Also, depending on how you shutdown your server(are you adding a shutdown hook?), you might not need the above.
On the other hand, you may implement and test lock(-1), but never use it: as I recall, using the lock(-1) is not required, either implicitly or explicitly, by the exam.

HTH,
M, author
The Sun Certified Java Developer Exam with J2SE 1.4

[BJ Grau]

Sam -
Try not to design your system so that you have a need to lock the entire database during normal operation. Then go with your assumption about server shut-down; this will preclude you from having to implement an unlock(-1) method and will make life simpler overall.
-BJ

[Max Habibi]

BJ-
No matter what, you have to implement lock(-1), and you have to do it correctly. However, you don't have to use it.
M

[Amit Kr Kumar]

Hi Max

Are you going to stop accepting lock requests once a lock(-1) record comes in, or are you going to process them normally?

Should we stop accepting lock requests once a lock(-1) record comes in ???
Dont u think it may result into deadlock in future. Not as per the current requirements, but when c client will be allowed to 2 or more locks at one time.
Amit

[Max Habibi]

Hi Amit,
You absolutely shouldn't code this project to anything other then the given requirements. It's a bad idea to code for vaporous requirements in general, and SUN will mark you off if you do it here.

Don't u think it may result into deadlock in future. Not as per the current requirements, but when c client will be allowed to 2 or more locks at one time.

Not at all, If you implement your locking strategy correctly. Consider the alternative: a user who wants to lock the entire db will probably suffer starvation, because he will have to wait for every other client to unlock every record, while other users will only, potentially, only wait for a single record, unless there are no other clients. The trick, if you use a hashTable for locking records, is to make the recordID the key, and GUI_ID(or ThreadID, depending on your implementation) the value.
HTH,
M, author
The Sun Certified Java Developer Exam with J2SE 1.4
[ July 25, 2002: Message edited by: Max Habibi ]

[Eduard Jodas]

Are you going to stop accepting lock requests once a lock(-1) record comes in, or are you going to process them normally?

In my implementation if someone locks the database (lock(-1)) then all lock requests block until the db is unlocked (unlock(-1))
If a record is locked then a lock(-1) request blocks. Further record lock requests are accepted, though. Thus, the lock(-1) requester may suffer starvation, but I don't care since lock(-1) is a costly operation that may slow down all other clients and must be penalised, and the alternative is deadlock prone.
I don't think this is all very important, as long as you comment your decision and defend it.

[Amit Kr Kumar]

Thanks Max
However in my case, i have used a hashset and not hashmap. It is with Data's LockManager and does not contain any info abt who have locked what. It just knowns what all records are locked.
I have a connection factory which is binded in connection factory and generates and give connection (RemoteDataAccess) objects to clients when its getConnection() method is called.
Every client has its own unique object.
This connection has all the methods of Data class. It keeps a record of what all records it has locked in a hashset. When lock method of this connection class is called it first class lock (rec) method of Data class where actual locking is perfomed using wait monitor and then it adds this record no in its own hashset to update itself. This is helpful in case of unlock. Thus unlock calls can be ignored if it has not locked by the same client.
Every connection known what all records it has locked.
I could have used a RemoteLockamanger which keeps record no as key and clientid as value. But i have not done that becoz for this i had to leave the lock and unlock methods of Data class empty. I do not wnat to take the chance of leaving them blank.
Is this design correct ???
Amit

[Max Habibi]

Hi Amit.
I may not be following your design, but it sounds like the client's are not allowing themselves to call unlock if they don't currently have the record. This is a clever idea, and a practical one.
However, it does not meet the requirements of the unlock method, as they were presented to me. That is, my unlock method (in the data class) required that the calls be ignored if the person attempting to unlock didn't actually own the lock. That's not what's happening in your case: in your case, your just promising that the client will not try to unlock records that they don't own. In the requirements (as I understand them), this responsibility falls on the Data class. You've deferred the responsibility to the client. It's a subtle, but important, difference.
If you decide to consider another approach here, then you'll need to provide some way for the Data class to keep track of the clients doing the locking. This will likely suggest the usage of a Map of some sort. This can be either through a ClientID, or, if each client gets their own thread, the ThreadID. I recommend the latter.
HTH,
M, author
The Sun Certified Java Developer Exam with J2SE 1.4

[Max Habibi]

Originally posted by Eduard Jodas:

I don't think this is all very important, as long as you comment your decision and defend it.

HI Eduard,
I like your design. However, I disagree that this is not that important. I'd wager that the locking(and the searching) are the only two parts of your code that the reviewer will actually look into, in terms of code inspection. And I think that locking is worth quite a few points, though the number escapes me right now.

M, author
The Sun Certified Java Developer Exam with J2SE 1.4

[BJ Grau]

Originally posted by Max Habibi:
BJ-
No matter what, you have to implement lock(-1), and you have to do it correctly. However, you don't have to use it.
M

Thats right Max, but just to make sure we are on the same page, note that I was referring to not having to implement an unlock(-1) method.

[Max Habibi]

BJ,
I don't think it would be reasonable to provide the ability to lock a record, or the entire db, without providing the mechinism for unlocking it. If I were reviewing the exam, I would probably mark off for that. Depending on how you implement your locking stragegy, the unlock can be free.
HTH,
M, author
The Sun Certified Java Developer Exam with J2SE 1.4

[Sam Stackly]

Hi Guys,
I was reading some thread about lock(-1) and I've read lot's of guys tried to loop through all records and get the lock for each record during database lock, since I assume Lock Manager is a seperate class , how does it know about number of record in Data class ?? I am totally lost please help
Thanks
Sam

[BJ Grau]

Originally posted by Max Habibi:
Depending on how you implement your locking stragegy, the unlock can be free.

What do you mean by free? Also, I think it would be justified to not implement unlock(-1) if lock(-1) was interpreted to be for a special case such as server shutdown. No need to unlock(-1) when nothing is running. As long as one can clearly document why this was done the graders should not take away points.

[Robin Underwood]

I did the lock(-1) a little differently. I set a boolean to not allow any new client locks. Then my lock(-1) method will wait until all existing client locks have been removed (either through client unlocks or expiration).
I assumed that lock(-1) would be used for system shutdown or maintenance, so clients attempting to get new locks will get an exception with the message "Database is locked", rather than having to wait for unlock(-1).
I recommended implementing unlock(-1) even if it isn't called. Mine was just a few lines of code and just reset the boolean after making sure that the client was the same one that requested the lock(-1).

[Max Habibi]

Hey Sam,
The first thing you should do is order my book . After that, here are some general strategies to consider, in terms of general record access and locking.
1) Load the entire db into memory. This has the advantage of trivalizing seaching speed, and minimizing your access time to the filesystem, thus reducing the chances for an IO error. It has the disadvantage of forcing you to keep this 'cache' and the actual database file synchronized. You'll appreciate the latter if you've ever built a database from scratch. This is probably the reason people are talking about locking records as they're read.
2) Access the db directly, with no cache at all. This is the more traditional implementation. The advantage here is that your avoiding synchronization issues(that is, database/cache synchronization, not java synchronization). The data only exists in one place, and that's the end of the story. The disadvantage is that it's not as fast.
Best regards,
M, author
The Sun Certified Java Developer Exam with J2SE 1.4
[ July 25, 2002: Message edited by: Max Habibi ]

[Max Habibi]

Originally posted by BJ Grau:
What do you mean by free?

I mean that your unlock wouldn't require any logic beyond the code require to release any normal record number. It's all a matter of your design.

Originally posted by BJ Grau:

if lock(-1) was interpreted to be for a special case such as server shutdown. No need to unlock(-1) when nothing is running. As long as one can clearly document why this was done the graders should not take away points.

You could interpreted it that way: however, in my opinion, such an interpretation is not supported by the exam's requirements. IMO, doing so is taking a risk with a non trivally priced test. It is safer to simply implement your unlock then to take that risk. It's also more interesting and better craftmanship: don't build boxes you can't get out of. Again, these are just suggestions, take them for what there's worth to you.
Best regards,
M, author
The Sun Certified Java Developer Exam with J2SE 1.4

[Max Habibi]

Hi Robin,
That's nice design, I like it.
M, author
The Sun Certified Java Developer Exam with J2SE 1.4

[Robin Underwood]

Load the entire db into memory. This has the advantage of trivalizing
seaching speed, and minimizing your access time to the filesystem,
thus reducing the chances for an IO error. It has the disadvantage
of forcing you to keep this 'cache' and the actual database
file synchronized. You'll appreciate the latter if you've ever
built a database from scratch. This is probably the reason people are talking about locking records as they're read.

I would avoid caching. This could have a performance problem with larger databases.

[Sam Stackly]

Hi Robin,
I like ur design too, seems simple and straight, and it was my first thought too, but after reading lots of comment about looping through all records and get lock for all of them I changed my mind - the only problem with reading all records is dealing with a big database file, and thosands of records, so I may change my mind again!! back to your desing. just a question about lock and unlock , how did you deal with a record which was locked by a non-existing client( or in other was what if client gets the lock and after it crash or something in his connection?
Thanks again
Sam

[Max Habibi]

Originally posted by Robin Underwood:

I would avoid caching. This could have a performance problem with larger databases.

So would I. I was wanted to point out the advantages and disadvantages of both approaches.
Best regards,
M, author
The Sun Certified Java Developer Exam with J2SE 1.4

[Robin Underwood]

how did you deal with a record which was locked by a non-existing client
( or in other was what if client gets the lock and after it crash or something in his connection?

I keep track of each lock's expiration time. I have a background clean-up thread that cleans up stale locks. Also, a lock request will check if an existing lock is expired but not yet cleaned up.

[Nate Johnson]

Hi Robin,
I saw that you posted that you took your essay... just wondering if you have heard anything back from Sun yet?
Thanks,

[Robin Underwood]

Nate,
I took the essay 7/13. Still no results yet. I sent an email to [e-mail] and received an email back that it was assigned to an assessor on 7/15.
When did you take your exam and have you heard anything?

[BJ Grau]

Originally posted by Robin Underwood:
I did the lock(-1) a little differently. I set a boolean to not allow any new client locks. Then my lock(-1) method will wait until all existing client locks have been removed (either through client unlocks or expiration).
I assumed that lock(-1) would be used for system shutdown or maintenance, so clients attempting to get new locks will get an exception with the message "Database is locked", rather than having to wait for unlock(-1).
I recommended implementing unlock(-1) even if it isn't called. Mine was just a few lines of code and just reset the boolean after making sure that the client was the same one that requested the lock(-1).

Great design Robin, thanks for sharing it with us.

[Max Habibi]

Originally posted by Robin Underwood:

I keep track of each lock's expiration time. I have a background clean-up thread that cleans up stale locks. Also, a lock request will check if an existing lock is expired but not yet cleaned up.

Nate,
This part might have been overkill, depending on your design. If each client gets thier own thread(as in, say, a factory based RMI network approach), then you can use a WeakHashMap to store locked records in. As you know, the value of a WeakHashMap is that when a key object loses all references to it, it is released, as is the value object. The elegence of this approach comes in using the Thread itself as the key for the WeakhashMap, and the recordID as the value. This way, when a thread dies, it will eventually release the record. Thus, there's no need for a reaper thread.
HTH,
M, author
The Sun Certified Java Developer Exam with J2SE 1.4

[Nate Johnson]

Originally posted by Robin Underwood:
Nate,
I took the essay 7/13. Still no results yet. I sent an email to [e-mail] and received an email back that it was assigned to an assessor on 7/15.
When did you take your exam and have you heard anything?

I am not quite there yet... I have to do my docs and touch a few things up... then take the exam.. i am looking forward to that day
Good luck to ya!

[Robin Underwood]

If each client gets thier own thread(as in, say, a factory based
RMI network approach), then you can use a WeakHashMap to store
locked records in. As you know, the value of a WeakHashMap is that when
a key object loses all references to it, it is released, as is the value
object. The elegence of this approach comes in using the Thread itself
as the key for the WeakhashMap, and the recordID as the value. This way,
when a thread dies, it will eventually release the record. Thus, there's no need for a reaper thread.

Max, I could be wrong but I thought there was no guarantee that a client will run in the same thread when using RMI.

[Max Habibi]

Originally posted by Robin Underwood:

Max, I could be wrong but I thought there was no guarantee that a client will run in the same thread when using RMI.

Hi Robin,
You're right that if multiple clients attempt to access the same remote RMI object, there is no quarentee that they will each have thier own thread.
However, consider the following.
A singleton RMI factory object, which has only one purpose in life: to create unique RMI DataServer object for GUI clients. Thus, each gui object gets thier own RMI DataServer object. Since there is no sharing(because each GUI client has thier own DataServer), you are guaranteed that each client gets thier own thread.
Think of it RMI factory object as a Home object, per ejbs, and it all falls into place.
HTH,
M, author
The Sun Certified Java Developer Exam with J2SE 1.4

[Sam Stackly]

I keep track of each lock's expiration time. I have a background clean-up thread that cleans up stale locks. Also, a lock request will check if an existing lock is expired but not yet cleaned up.

Did you used Timer or anything else ?Cause I think using Timer is overkill, I can't think about anything else , can you explain this for me?
Thanks
Sam

[Robin Underwood]

Did you used Timer or anything else ?
Cause I think using Timer is overkill, I can't think about anything else , can you explain this for me?

I keep a collection of lock objects, and each object holds onto its expiration time. I calculate the expiration time by adding a predefined number of milliseconds (from a properties file) to the current time when the lock object is created.

[Sam Stackly]

Thanks Robin, you were very instructive
Did you use Timer for starting clean up thread??

Thanks again
Sam

[Robin Underwood]

I didn't use Timer. I just used the Thread class, and had the run method in a loop where it would wake up and perform a cleanup method.

[Sam Stackly]

thanks again
good night and good luck

Sam

[Nate Johnson]

Originally posted by Max Habibi:

So would I. I was wanted to point out the advantages and disadvantages of both approaches.
Best regards,
M, author
The Sun Certified Java Developer Exam with J2SE 1.4

(For caching the data vs going at the db every time...) What about for the JTable? I am using an AbstractTableModel and I have a DataInfo [] of all of the rows in the table stored in the TableModel. Do you think this is a bad idea? Would it be better to store the current search criteria in the TableModel, then perform a search every time the table refreshes?
Thanks,
[ July 25, 2002: Message edited by: Nate Johnson ]

[Amit Kr Kumar]

Hi Max

Hi Amit.
I may not be following your design, but it sounds like the client's are not allowing themselves to call unlock if they don't currently have the record. This is a clever idea, and a practical one.
However, it does not meet the requirements of the unlock method, as they were presented to me. That is, my unlock method (in the data class) required that the calls be ignored if the person attempting to unlock didn't actually own the lock. That's not what's happening in your case: in your case, your just promising that the client will not try to unlock records that they don't own. In the requirements (as I understand them), this responsibility falls on the Data class. You've deferred the responsibility to the client. It's a subtle, but important, difference.
If you decide to consider another approach here, then you'll need to provide some way for the Data class to keep track of the clients doing the locking. This will likely suggest the usage of a Map of some sort. This can be either through a ClientID, or, if each client gets their own thread, the ThreadID. I recommend the latter.

i agree with you that it should be done by Data but the problem is the lock() inside Data takes only record number as argument and nothing else.
Thus i can not pass the ClientID (RemoteDataAccess) object to this method ??
Will it be correct to modify the method signature of Data class to accomodate clientid ??
*********************************
Robin, how did u handled this situation
*********************************
Amit

[Max Habibi]

Originally posted by Nate Johnson:
Would it be better to store the current search criteria in the TableModel, then perform a search every time the table refreshes?
Thanks,
[ July 25, 2002: Message edited by: Nate Johnson ]

Hi Nate,
If I understand your question properly, then yes, I think your latter idea is a better one. Remember, performace is not an issue in this application.
HTH,
M, author
The Sun Certified Java Developer Exam with J2SE 1.4

[Max Habibi]

Originally posted by Amit Kr Kumar:
Hi Max
i agree with you that it should be done by Data but the problem is the lock() inside Data takes only record number as argument and nothing else.
Thus i can not pass the ClientID (RemoteDataAccess) object to this method ??
Will it be correct to modify the method signature of Data class to accomodate clientid ??
*********************************
Robin, how did u handled this situation
*********************************
Amit

Hi Amit,
You have several options here, depending on how you implemented your design. However, I would be reluctant to change any method signatures.
If each client has their own data object, then you're almost done. Simple store the ClientID in the Data class(that is, add a client ID member variable to the Data class, and overload a constructor to allow the clientID to be set: or keep a static member variable called ClientID, and increment it each time a client requests a new Data Object, thus keeping the client from knowing that it even has an ID). Either way, you can use that to lock the record. I don't want to give away any more, because I don't want to compromise your exam, but these are sorts of solutions you should look at.
HTH,
M, author
The Sun Certified Java Developer Exam with J2SE 1.4
[ July 26, 2002: Message edited by: Max Habibi ]