database lock

[Prakash Krishnamurthy]

When the database is locked, would it need to have a read lock too? You would need a write lock on the database since you should not be able to access any record for locking/unlocking.
So if the database is locked should the user be able to still see all the records in it?
Prakash

[Andrew Monkhouse]

Hi Prakesh,
From my copy of the instructions from Sun:

Note that the locking required is effectively a write lock only.

The general opinion of this forum seems to be that handling dirty reads is outside the scope of this assignement.
Regards, Andrew

[shan chen]

Andrew,
I have a further question about lock. It is for sure that in remote mode write lock must be implemented. What about in local mode?
1. should not implemente lock
or
2. using lock or not using lock, both are acceptable.
any suggestion?
shan

[Andrew Monkhouse]

Hi Shan

It is for sure that in remote mode write lock must be implemented. What about in local mode?

I think the answer depends on where your locking code is, in both the GUI and in the Database.
From the database perspective, you can code the locking into the suncertify.db.data class itself, or you could code it into the classes that handle network connectivity.
Likewise on the GUI side, many people seem to be building a connection factory to handle the local vs remote technical details. You can put the locking code in the connection factory's network specific code (in which case the GUI only calls an "updateDatabase" method, and the network version of the updateDatabase method handles the locking and unlocking of the record), or you can put the locking code into the GUI itself (so it calls "lock", "updateDatabase", and "unlock").
Now - in the case where your locking code is in the networking section of the database, and in the networking section of the connection factory, you could have the local mode do no locking.
I think that the same might apply if you have your locking code is in the suncertify.db.data section of the database, and in the networking section of the connection factory.
However, if you have the locking code in the GUI application iteself, then you really want to do locking in local mode as well, because if you dont, then you have different GUI code for local vs remote mode, and that should be transparent to the GUI. (Not to mention the problem for anyone maintaining your code (think examiner), where they have to look at two sections of code that are supposed to be doing the same thing.
Now having said all that, my personal belief is that locking should be done whether local or remote.
My reason is that locking the record is a blocking method. Therefore I want to give the user feedback that I am attempting to lock the record, I am updating the record, I am unlocking the record. If I dont do that, then the user may think the application has crashed when it is attempting to get a lock.
If the locking code is all done on the database side (no code at all on the client side), then I cannot do this.
If the locking code is in the network specific code, then the user is going to get different messages depending on which mode they are in (unless you fake the messages) - I would prefer to have it such that the user is unaware of which mode they are in.
Hope this gives you some things to think about.
Rememer there is no one right way, so other people may disagree with me, and you are free to choose your own way.
Regards, Andrew

[Prakash Krishnamurthy]

Shan chen, whether or not you need to implement lock in local mode is a design decision. The requirements dont say that it is needed in local mode, nor does it say and it is not needed in local mode.

Andrew,
I am not sure i got my question answered. When there is a database lock, should the user be able to do a search on the origin and airport destinations? Should the JTable just show as 0 records and say that, the database is locked? Or should he/she be able to do the search but not able to book anything since the database is locked?
Regards,
Prakash

[Andrew Monkhouse]

Hi Prakash,
I missunderstood your question - sorry.
In the real world, I believe you would be correct - when the entire database is locked then you would not allow reading, since the only reason for locking the entire database is to do some major change to it.
However the write locks are blocking calls - as required by the specification. Do you have the read call also block (definately not what the user was expecting) or do you have the database throw an IOException if the database is locked (more friendly but it means that different sections of the database behave differently to locks).
The problem is that for completeness you would then be tempted to consider read locks on records.
And we are getting out of scope.
My answer is: documentation: If you decide to allow reads during database locks, add a comment to the JavaDoc documentation stating that it may return dirty data. If you decide to throw an exception: again docuement why in your JavaDoc comments, and make a comment about record read lock considerations.
I think either method could be acceptable.
As for your other case scenario: not allowing bookings because the data was read during a database lock - I would not go there. This opens up a whole can of worms as to the validity of data at the client, and it's lifetime.
If you decide to allow reads during a database lock, then allow bookings as well. The scenario is no different to me doing a criteriaFind, going to grab a coffee, then making a booking. but while I was making coffee, someone changed the database.
If you are doing a short sell - just sending the unique identifier and the number of seats requested - then in either case you may not get what you asked for.
If you are doing a long sell - sending the entire flight specification - then in either case if the record in the database has changed then your sell will fail.
Regards, Andrew

[shan chen]

Thanks Andrew.

[Erik Manor]

My instructions state

You may assume that at any moment, at most one program is accessing the database file

I read this as meaning even reads need to reguire a lock?