It's not a secret anymore!*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes URLyBird 1.2.3 Unnecessary locking? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Android Security Essentials Live Lessons this week in the Android forum!
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "URLyBird 1.2.3 Unnecessary locking?" Watch "URLyBird 1.2.3 Unnecessary locking?" New topic
Author

URLyBird 1.2.3 Unnecessary locking?

Fred Beltr�o
Greenhorn

Joined: Feb 24, 2005
Posts: 10
Quotes from intructions.html:


Server
Required Interface
Your data access class must be called "Data.java", must be in a package called "suncertify.db", and must implement the following interface:



So my Data class always claims for a SecurityException regardless I am in server or standalone modes.

However, the quote from the instructions.html below states:


... therefore your locking system only needs to be concerned with multiple concurrent clients of your server.


Why should I thrown a SecurityException if I am in standalone mode??
Do you perform locks and unlocks even in standalone mode?

Thanks in advance!


Fred Beltr�o<br />SCJA<br />SCJP 1.4<br />SCJD (in progress)
Andrew Monkhouse
author and jackaroo
Marshal Commander

Joined: Mar 28, 2003
Posts: 11404
    
  81

Hi Fred,

However, the quote from the instructions.html below states:

"therefore your locking system only needs to be concerned with multiple concurrent clients of your server"


I think you are taking this statement out of context. The complete sentence is:
You may assume that at any moment, at most one program is accessing the database file; therefore your locking system only needs to be concerned with multiple concurrent clients of your server.
As such it is suggesting that you do not need to concern yourself with file level locking - you only need to do record level locking.

Why should I thrown a SecurityException if I am in standalone mode??
Do you perform locks and unlocks even in standalone mode?


Turn the question around - if you are not doing this, then you are writing separate code for standalone and networked mode. Do you really want to be maintaining two separate codebases? What is the downside to performing locks in standalone mode?

Regards, Andrew
[ March 21, 2005: Message edited by: Andrew Monkhouse ]

The Sun Certified Java Developer Exam with J2SE 5: paper version from Amazon, PDF from Apress, Online reference: Books 24x7 Personal blog
Cleverson Schmidt
Ranch Hand

Joined: Feb 17, 2004
Posts: 55
Hi Andrew, Fred

Please allow me to use this thread as my question is related to what is under discussion here.

>> What is the downside to performing locks in standalone mode?

The only downside is a small loss in performance. But as high performance is not a requirement for this project, I think we don't need to worry about this little drawback.

Even so, I'm still wary. I'm not a English native speaker, so my understanding of the following sentence may be biased by this fact.

"..your locking system only needs to be concerned with multiple concurrent clients of your server"

If the specification states that we need to provide a locking system which only needs to be concerned with multiple concurrent clients and we provide a locking system which locks records even when there is just one client (standalone mode), aren't we breaking this rule of just providing a locking system for multiple clients?

Another question. If we choose not to call lock/unlock on the standalone mode, what should we provide as lockCookie for the methods which requires such parameter like update?

Once more thank you very much for you great help.

Best Regards
Cleverson Schmidt
[ March 21, 2005: Message edited by: Cleverson Schmidt ]
Frans Janssen
Ranch Hand

Joined: Dec 29, 2004
Posts: 357
Originally posted by Cleverson Schmidt:
"..your locking system only needs to be concerned with multiple concurrent clients of your server"

If the specification states that we need to provide a locking system which only needs to be concerned with multiple concurrent clients and we provide a locking system which locks records even when there is just one client (standalone mode), aren't we breaking this rule of just providing a locking system for multiple clients?


Hi Cleverson,

As Andrew pointed out above, this statement is only meant to emphasize that you do not need to do any file level locking. Note that the sentence does not contain the word "must", so it does not describe a requirement that you must follow.

Another question. If we choose not to call lock/unlock on the standalone mode, what should we provide as lockCookie for the methods which requires such parameter like update?


You will probably violate your interface specification if you make the update/delete methods accept cookies other than those returned by the lock method. So that's why I think you must lock/unlock your records even in local mode. It also much easier if you don't need to provide local and remote specific behavior, so you will make your assignment a lot easier if you use locking in local mode too.

Don't worry that you will be penalized for using local mode locks: In wasn't and I don't tbink anyone on this forum has ever been.

Frans.


SCJP 1.4, SCJD
Fred Beltr�o
Greenhorn

Joined: Feb 24, 2005
Posts: 10
Andy, Cleverson and Frans,

Thank you very much for the answers and comments! Now I'm right to use lock in both standalone and remote modes.

Best regards!
 
Consider Paul's rocket mass heater.
 
subject: URLyBird 1.2.3 Unnecessary locking?
 
Similar Threads
Should lock methods be callable by the client
NX: package problem
Simple question about Data Access Component
What shall Data class really do?
NX: Some question about DBAccess