>>Programs that access the database are the client threads. Each thread processes a client request (a search or a booking operation).
>>With URLyBird (as with most of the client-server systems), the end-client is the GUI.
>>Of course you can have many clients (many GUI) that want to access the database in local or networked-mode.
>>So you have to make sure that a write operation for a given record at a given time is allowed to one and just one thread.
So as I understood concurrency must be provided in both modes.
But my sun assignment says:
>>Your server must be capable of handling multiple concurrent requests, and as part of this capability, must provide locking functionality as specified in the interface >>provided above. 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. Any attempt to lock a resource that is already locked should cause the current thread to give up the CPU, >>consuming no CPU cycles until the desired resource becomes available.
There is nothing about the local mode concurrency, only about servers.
So what do you think I should do ?
Local mode concurrency is really your locking mechanism for your Data class. For example, you need to explicitly call Data's lock method then update/delete then unlock in this order to do any updates/deletes. So say after you sucessfully update the first time, and hang on the second time your locking mechanism is in trouble.
If you can do update/delete in local mode, the network mode is simply allowing multiple threads to access your Data class.
K. Tsang CEng MBCS PMP PMI-ACP OCPJEA OCPJP
Oh sure, it's a tiny ad, but under the right circumstances, it gets bigger.
Devious Experiments for a Truly Passive Greenhouse!