Data: Mutition/Singletone

[Wojtek Polczynski]

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

[Philippe Maquet]

Hi Wojtek,
1. Yes.
2. Yes, but.
3.a You'll get a problem with "half-static" data, like a cache. Within a single-table system, people implement a cache as a static structure. In a multiple-tables system, a cache must be static at the physical table level, meaning an instance variable in your multiton design. Now, if you have one Data instance per client, what to do with such a cache (same issue for other share data at the file level BTW).
3.b Not a good idea IMO. Your db access layer should ideally support any network technology.
2 + 3a combined : Imagine that you keep your Data multiton unchanged, but rename your Data class as DataFile for instance. In DataFile, you may change all signatures to fit your needs, right ? So you'll change lock() and unlock() to add an additional parameter representing a connection to your database (same as a client). In Data (one instance per client/file pair) you put a parameter in the constructor (it's up to us to define the Data constructor) representing the connection/client. In this constructor you save the connection object in some Data private variable and get a reference to the right DataFile instance. And you implement all Data methods by a simple call to DataFile...
It would give something like this :

Data\
     \
Data-- DataFile
     /          \
Data/            \
                  --- LockManager
Data\            /
     \          /
Data-- DataFile/
     /          
Data/           

4. OK, as far as you keep an intermediary multiton.
5. Yes
6. Agreed 100%. As I wrote previously, deadlock detection is not a requirement. Mentioning the issue and the possible improvement in your design document is enough IMO. Now if you implement a design comparable to the one I just described, it could be a pity to stop just before the deadlock detection method. After all, it's just 20 additional lines. So if you don't do it, I would suggest to avoid the additional layer I have myself.
After this little SCJD-break, I'll keep going with my SCBCD exam study.
Best,
Phil.
[ November 25, 2003: Message edited by: Philippe Maquet ]

[Wojtek Polczynski]

Phil,
Thank you for your help. Now I am able to create my own data / network design and defend it. (I hope so. )
Good luck with your SCBCD and SCJD-break. I also would like to go to Java Enterprise Edition but first I have to finish this assignment.
Thanks,
Wojtek

[Terry Martinson]

I have read through this post and am still thinking about the singleton/multiton issue. My beginning approach has been singleton, and I also have a Data.getInstance(String fileName) method which tends to look like the multiton approach.
Here are my questions -
1. When running either the client GUI (alone mode) or the server GUI (remote mode), I have already forced the user to enter the database file name. Could I just have the Data.getInstance() method get the file name from the properties file in the case that it has not yet been instantiated?
This would solve the problem of a singleton's getInstance method looking like the singleton approach rather than multiton and also enforce using the user-entered database file name.
2. However, would this be a problem for Sun's automated testing? I don't know much about this or whether or not I would need to provide them with a constructor that accepts a file name. I did not see anything specific in the specs regarding this.
3. These posts really make it look like singleton is not good enough, but I'm wondering if people have passed using the singleton approach. I am trying to keep this as simple as I can because I just want to somehow someday be able to finish the assignment and am hoping I can do it with the simpler singleton approach.
Sorry if these are dumb questions.
Any help appreciated.

TJ

[Andrew Monkhouse]

Hi Terry,

1. When running either the client GUI (alone mode) or the server GUI (remote mode), I have already forced the user to enter the database file name. Could I just have the Data.getInstance() method get the file name from the properties file in the case that it has not yet been instantiated?
This would solve the problem of a singleton's getInstance method looking like the singleton approach rather than multiton and also enforce using the user-entered database file name.

You could do that. This would mean that your Data class can only work with the one data file which is specified in the properties file. In which case your Data class might as well be a Singleton
This also ties your Data class to a particular property from the Properties file. If the person coding the server later feels that this particular property is all wrong for their particular application, they cannot change it. Likewise, if the person coding the server decided that they wanted to use the Preferences API rather than the Properties API, they cannot.
So your Data class is dictating how the Server acts.

2. However, would this be a problem for Sun's automated testing? I don't know much about this or whether or not I would need to provide them with a constructor that accepts a file name. I did not see anything specific in the specs regarding this.

No matter how you get around this issue, you are going to have to document clearly how a user can instantiate your Data class. Regardless of how you do it, the examiner will have to do some coding on their side in order to automate the testing.

3. These posts really make it look like singleton is not good enough, but I'm wondering if people have passed using the singleton approach. I am trying to keep this as simple as I can because I just want to somehow someday be able to finish the assignment and am hoping I can do it with the simpler singleton approach.

I think you can pass with a Singleton Data class. As always it comes down to a design decision which you have to document. As long as you explain what you did and why you did it you should be fine. It sounds like you know the reasons why most of us believe that a Singleton is not a good idea. You could try mentioning these reasons in your document along with why you dont believe that they apply, and why you believe that a Singleton does apply.
Regards, Andrew

[Vlad Rabkin]

Hi Terry,
I totally agree with Andrew.
Whatever solution you choose, document it heavily. I used multiton, but I described possible solution with singletone and all disadvantages and advantages of each approach.
Best,
Vlad

[Ken Krebs]

Terry,
Using a singleton is just fine. I used it basically because it's simpler and only provided a single sentence explaining that in my "choices.txt". IMO, providing the ability to serve more than 1 file is beyond the scope of the assignment.
For a detailed description of my design see the
NX: Notes on a design that passed 389/400 thread.
kktec
SCJP, SCWCD, SCJD
"The journey is the reward."