URLyBird 1.2.3 Unnecessary locking?

[Fred Beltr�o]

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:

package suncertify.db;
public interface DBAccess
{
   ...
   public void updateRecord(long recNo, String[] data, long lockCookie)
throws RecordNotFoundException, SecurityException;
   ...

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!

[Andrew Monkhouse]

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 ]

[Cleverson Schmidt]

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]

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.

[Fred Beltr�o]

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!