I would argue that Data should not implement locking... in another thread I said:Originally posted by Yuqing Zhu:
Modify supplied Data class to implements DataAccess, implement lock and unlock method. The implementation uses a Hashtable, key is Integer object of record number, value is the current thread reference (more on this later).
But, to be honest, no-one is going to be really worked up about this point, least of all the Sun assessors.For example, do not assume that lock() and unlock() need to be implemented on Data. They are fine as they are. Yes, that means empty methods. Really! If you want to, you can flesh them out a bit by adding validation code for the record number, but the lock() and unlock() methods in Data do not need to implement locking at all.
Why not? Well, think a bit about what Data represents. It represents a local database that can only be used from a single JVM. It is a single-user database object that consequently should not try to implement any of the multi-user features, such as locking. Locking is part of a network-enabled, multi-user layer that is built on top of Data.
With a layered architecture such as this, you achieve clear separation of responsibilities, maximum ease of use (a developer only needs to deal with the multi-user networked stuff when (s)he needs a multi-user networked database) and the highest level of reusability.
Oh yes you do! In that hypothetical case, the client requests are serialized in that no more than one method call is handled any given time. But the calls can be interleaved and bookings can still clobber each other:Now, let me defence my choice of using current thread reference as client identity. As mentioned in RMI specification, there is no guarantee on how RMI runtime will handle the incoming client request,it may one, create a new thread for each client request, or second, run all client requests to a remote object instance in one single thread, i.e. no concurrency.
In the second case, I don't even need to lock the record before booking a seat
It certainly can not. RMI gives you no guarantees whatsoever that the same thread will be used for the same client every time! It may maintain a thread pool of 2, 3, maybe 10 threads and a client may get a different thread for every method call it makes.In the first case, things are easy, RMI handles everything for me and each client can be sure identified by its new thread reference.
Duck, quicklyDo you think this reasoning is fine enough? Any incoming comment will be appreciated.
Peter den Haan | peterdenhaan.com | quantum computing specialist, Objectivity Ltd
I would argue that Data should not implement locking... in another thread I said:
......
Why not? Well, think a bit about what Data represents. It represents a local database that can only be used from a single JVM. It is a single-user database object that consequently should not try to implement any of the multi-user features, such as locking. Locking is part of a network-enabled, multi-user layer that is built on top of Data.
Oh yes you do! In that hypothetical case, the client requests are serialized in that no more than one method call is handled any given time. But the calls can be interleaved and bookings can still clobber each other:
It certainly can not. RMI gives you no guarantees whatsoever that the same thread will be used for the same client every time! It may maintain a thread pool of 2, 3, maybe 10 threads and a client may get a different thread for every method call it makes.
Ah, that wasn't clear to me. If you put a session facade on the server, your scheme makes sense.Originally posted by Yuqing Zhu:
Yes, that's the point why we can't use thread as client's id when we put the facade in the client side.
Peter den Haan | peterdenhaan.com | quantum computing specialist, Objectivity Ltd
You are HERE! The other map is obviously wrong. Better confirm with this tiny ad:
Smokeless wood heat with a rocket mass heater
https://woodheat.net
|