locking assumptions

[mike acre]

Some assumptions I have made, perhaps someone could corroborate.

The lock cookie required to delete or update is an optimisation feature so that only individual records are locked as opposed to the entire update or delete operation ie locking a single record as opposed to all records.

The lock/unlock methods do not need to be called by the gui client, but merely by the request/connection object that identifies the client server side.

This last statement does not agree with what I have read, but what I have read does not explain itself satisfactorily.

[mike acre]

I think i understand why the gui must lock and unklock - it is so it can be certain that before a modify, the record is as expected.

By implementing this, my 1st point is realised, ie locking is minimised to a single record therefore maximising concurrency.

What if a client locks a record and then goes AWOL?

1/ should the locking be timed out server side?

2/ Should an attempts to lock/unlock be forced to be serial
ie can't do lock(x) lock(y) unlock(x) unlock(y)
rather lock(y) above forces an unlock(x)

3/ Should clients be written to send an 'unlock all for this client' request on shutdown?

2/ does not protect against client going AWOL

3/ Puts onus on client and shutdown requests can't be guaranteed

Any other strategies folks?

[mike acre]

This is getting ridiculous.
unlock() throws RNFE and RNFE is documented as :

Any methods that throw RecordNotFoundException should do so if a specified record does not exist or is marked as deleted in the database file.

so when a client does

lock > delete > unlock

unlock will throw RNFE!

Obviously a nonsense, another case of observe, document and move on?

the quote above says 'should' not 'must'. It would be daft to throw an RNFE in this case, yes?

Or should I not commit changes until the unlock method?

[Robert Konigsberg]

If you've got the B&S, then you don't actually have software requirements for performing a "delete" activity. You could very well just indicate that you discovered an anomaly in your choices.txt file, and say, "Boy I'm lucky we don't need to implement this, but if I did, I'd handle it by ..." and happily moving along.

Good catch!

[mike acre]

I have UyB, but I can't see any requirement for delete client side either.

Any comments on clients rudely not unlocking?

Timeout seems the best option with a refresh at each request.

Are people treating SecurityExceptions the same for cookie matches and cookie not found? My provided docs just suggest the former.

* Throws SecurityException if the record is locked with a cookie
* other than lockCookie.

[Stephen Patrick]

Hi Mike

I have UYB as well which is still in progress. For my delete and create methods in my data class i simply throw a UnsupportedMethodException.

]think i understand why the gui must lock and unklock - it is so it can be certain that before a modify, the record is as expected.

I chose not to lock on the client for the following reasons. I see the cookie as being an aid for the lock\unlock process and does not need to be exposed to the client. I have a Data access object that runs on the server and contains all of the data access logic including lock\unlock. IMO I feel that this is a better choice consider what will happen if a relational db is chosen other than a data file at some point in the future would you still want to expose a lock cookie. The DAO encapsulates all db access logic therefore the client will not be impacted by a change to a relational db.


Also I only throw an SecurityException if a record is locked by a different cookie, I don't do anything if a cookie is not found I simply return as there does not seem much point as it should throw a SecurityException before getting to this stage if the cookie is locked by another client.

Regards

Stephen

[mike acre]

In reply to: Stephen Patrick

I chose not to lock on the client for the following reasons. I see the cookie as being an aid for the lock\unlock process and does not need to be exposed to the client. I have a Data access object that runs on the server and contains all of the data access logic including lock\unlock.

What happens when a client wants to book a room?
They see that the room is unbooked, book it, but they can't because some one has dashed in and beat them to it. how does your update method inform them of that?

if the client controls the lock process they can guarantee they will book the record in the state they read it.

IMO I feel that this is a better choice consider what will happen if a relational db is chosen other than a data file at some point in the future would you still want to expose a lock cookie. The DAO encapsulates all db access logic therefore the client will not be impacted by a change to a relational db.

With a RDBMS via JDBC we have the commit option this is synonymous with the lock approach.
With the assignment some level of security is provided by the cookie/lock and with RDBMS it is provided by SSL

AFAIK RDBMS operates via a more elaborate and often secure protocol. I don't think you can easily change between them.

My general networking knowledge is V. Poor so I can't really comment.
What I have written just above is shakey and misinformed at best, but it may invite discussion?!

Also I only throw an SecurityException if a record is locked by a different cookie, I don't do anything if a cookie is not found I simply return as there does not seem much point as it should throw a SecurityException before getting to this stage if the cookie is locked by another client.

So when you return and your method does nothing how can the client glean anything from this? Surely it is better defense to throw exceptions unless it went as intended?

Though by doing as you say you do follow the DB interface doc desription of when the SecEx should be thrown. I'm inclined to change the doc slightly.

[mike acre]

In Reply to: Robert Konigsberg

If you've got the B&S, then you don't actually have software requirements for performing a "delete" activity
I have UyB, but I can't see any requirement for delete client side either.

However, why should we assume that the requirements are all derived from the client side?
Should we not implement server function for future clients? especially since the interface is provided and assignment states:

and must implement the following interface

I'm not sure if just throwing ONS Exception will really cut it?

[Stephen Patrick]

Hi Mike, I am by no means an expert, but my opinion on the process.

What happens when a client wants to book a room?
They see that the room is unbooked, book it, but they can't because some one has dashed in and beat them to it. how does your update method inform them of that?

I think either way the record should always be re read when performing the book operation. Consider when a client, client A performs a search and receives a number of rooms that are displayed in the gui. Now while Client a is reading these records, Client B updates the record or books the record. Now client A wishes to book the same record but it has being modified.

Whether locking on the client or server you should abstract away the locking mechanism from the client by introducing some from of Data Model Layer such as a DataAccessObject. In my case I had this on the server as I don't need to worry about the client locking a record and crashing. So my DataAccessObject has a book method that will re read the record if it is different than the one the client has it will throw a BookingException indicating this fact.

if the client controls the lock process they can guarantee they will book the record in the state they read it.

The only way a client can guarantee that the record has not being modified is if they locked it while reading it but this will stop all other clients from using the record while it is simply being displayed and also need a complicated unlocking mechanism.

[mike acre]

The only way a client can guarantee that the record has not being modified is if they locked it while reading it but this will stop all other clients from using the record while it is simply being displayed and also need a complicated unlocking mechanism.

This is just a quick response, I'll digest your post properly later.

If a client does lock, read, update, unlock

It does not stop others reading the record.
Only modify operations are locked ie update/delete.

It just means that the client can be sure that the record state at update is the same as at read.

if a client did - read, (lock/update/unlock) - as you suggest (brackets indicate a single operation) from client perspective). Then nothing is stopping another client slipping in between read and lock.

stop all other clients from using the record while it is simply being displayed

While record is displayed no locking is done, when an update is requested
then client does - lock, read - if record still available it can book by continuing - update, unlock - If all is well these 4 requests will be done very quickly. If read returns a deleted or booked record then gui can respond accordingly. All is well in the world of URLyBird

DIGESTED!

I think I understand where you are coming from now.
I like it, since my 1st response at beginning of thread was to keep the lock/unlock server side.
[ July 11, 2004: Message edited by: mike acre ]