Hello Phil,
I would like to go back to our discussion concerning the design that supports multiple tables. I thought about your answer - about the deadlock prevention method. I came to the conclusion that was a little bit surprising to me. I have to redesign the data access system and network functionality completely. Could you be so kind and follow my decision-making process? If you find something, which does not make any sense, just make an �automatic failure�. This words really scare me.
Assumption:
I would like to crate a design that supports multiple tables. I showed you my approach in which I tried to use the following approach to achieve this goal:
- one Data per physical file (Multiton)
- Lock Manager as an instance variable of Data (not declared as static)
Unfortunately I missed the possibility of deadlocks which you described in the following way:
Client A is granted a lock on table1, recNo 100
Client B is granted a lock on table2, recNo 200
Client A is claiming a lock on table2, recNo 200
Client B is claiming a lock on table1, recNo 100
1. I think it is needed to use a client identification to write the deadlock prevention function. It impossible to write such functionality without such identification.
2. Using the following design...
a. one Data per physical file (Multiton)
b. long lock(int recNo) (from Data interface)
c. RMI as network approach
...it is impossible to identify clients unambiguously.
3. Therefore I have to choose one from the following possibilities:
a. create multi-Data approach (one Data per client)
b. use Sockets as the network layer
Because I want to use RMI there is just one option than I can choose.
4. I would like to create design based on:
a. Multi-Data approach (one Data per client)
b. Lock Manager (static variable, probably with the deadlock function)
c. FileHelper (file read/write functions, Multiton, one per physical file)
5. I thought about an algorithm of the detection function. Do you also use an additional memory data structure for keeping track of the records / clients that are in a wait state?
6. In the point 4b I wrote �probably� because I am caught in the middle right now. On the one hand I would like to design the application architecture exactly to the specification, on the other I would like to leave the design open for easy system extendibility � i.e. supporting multiple tables. Therefore I decided to create design described in the previous point without implementing the deadlock functionality. In my design choices document I would like to justify it in this way: �My main goal was to design according to the specification - that means to give the client exactly what he needs. Based on the specification current requirements of the client amount to the work with just one table. However the application architecture is open for the system expansion allowing for the work with many tables. In such a case the only thing, which must be done is add the deadlock detection function in Lock Manager. In this way the application satisfies current requirements of the client and still is open for further extensions with minimal cost.�
Is this design acceptable in your opinion?
Cheers,
Wojtek
So if you don't do it, I would suggest to avoid the additional layer I have myself.
