NX: database design pls review

[Rick Lu]

Hello,
After one week's studies, I got some ideas about the database structrure. Pls give some suggestions. I am not sure whether it is too simple...
1. DBMain interface from Sun
2. class MetaData for the data information like field names and lengths, etc. This class can provide MetaData information to clients.
3. class DataHelper with singleton pattern. this is for all file operations. I want to separate this from class Data.
4. class Data which implements DBMain interface. This is the presentation layer of the database. Just say, it is the model.
5. class LockManager, it uses WeakHashMap. Just like many other threads.
Because of one DataHelper per database, no concurrent reads are allowed. (I don't like the idea of caching the database). This is one main drawback. It can hurt the performance badly? Do you think whether this design is reasonable? Or just too simple.
And I have no intention to design something like RecordModel, ColumnModel since class Data is the business layer and it just use String all the time. Otherwise, I have to add another layer which can make codes more complex. Do you guys think RecordModel and ColumnModel are necessary to make your design more OO and clear?
Give me some suggestions. I hope the responsibility of each class is clear and simple to junior programmers. Is that possible Sun penalize me for this very simple design?

[Andrew Monkhouse]

Hi Rick,
Welcome to JavaRanch.
Simple is good. I have never heard of anyone being penalised for implementing a simple design, and there have been a lot of people who got really high marks with their simple design.
Reading between the lines, it sounds like your lock method does not return a cookie. In which case, everything you suggested sounds good to me.
Regards, Andrew

[Rick Lu]

Thanks Andrew.
Reading between the lines, it sounds like your lock method does not return a cookie.
I haven't much experience on WeakHashMap. What I am thinking now is to save the cookie in WeakHashMap, which is a member of class LockManager. And the cookie is only for the user who holds the lock.
[ September 28, 2003: Message edited by: Rick Lu ]

[Bharat Ruparel]

Hello Rick,
Please read again what Andrew is pointing out to you. You don't have a cookie in the DBMain interface. That allows you to use certain "simplifications" in your design. Don't think cookies! Another thing that you may want to keep in mind is that you may not need a separate class for the WeakHashMap data-structure, you can simply make it a member of your Data class and make it static so that only it is shared across multiple instances of the Data class.
Regards.
Bharat

[Rick Lu]

Hello Bharat,
Thanks for your reply.
But I feel a little bit confused now. What I am trying to do is that distinguishing different users when the server implements the lock mechanism. Therefore, the LockManager must remember something like cookies, maybe I shouldn't call them "cookies", to do so. These cookie-like values are saved in the server side. Never annoying clients.
My assignment is the "contractor". And the lock method defined in DBMain interface is:

// Locks a record so that it can only be updated or deleted by this client.
// If the specified record is already locked, the current thread gives up
// the CPU and consumes no CPU cycles until the record is unlocked.
public void lock(int recNo) throws RecordNotFoundException;
// Releases the lock on a record.
public void unlock(int recNo) throws RecordNotFoundException;

And instructions nerver talks about cookies. If I didn't make it clear before, sorry about it. I assume there are some other assignments that requires "cookie".
Pls let me know if I made some misunderstandings...
[ September 28, 2003: Message edited by: Rick Lu ]

[Bharat Ruparel]

Hello Rick,
Please take a look at the following thread. You should find your answer there:
NX: About data consistent
https://coderanch.com/t/183941/java-developer-SCJD/certification/NX-data-consistent
Regards.
Bharat

[Rick Lu]

Thanks Bharat.
IMO, using Data.this to lock the record is a quite smart idea. But I assume that Data.this reference is not a "cookie", right? since Bharat said in the previous replay " Don't think cookies! ".
I haven't studied enough on this assignment. So, maybe I have no idea how the "cookie" will affect the database design.
Bharat, ANdrew, if you have free time, could you let me know some about it?
Thanks.

[Bharat Ruparel]

Hello Rick,
You have the same interface, i.e., DBMain, that I have. There is no mention of cookies in my assignment except "Magic Cookie" which is different story. Disregard it for the time being since it validates authenticity of the data file serving data.
If you do that, you will see that there is no mention of Cookies in the DBMain interface. Usually, in my experience, which is heavily biased towards J2EE and web based development, the cookies represent the web, i.e., browser client. Moreover, cookies live on the client and when you are working with cookies you have to address the security aspect and the session management aspect. Your interface doesn't require you to deal with it. Cookies are used for client authentication and session-management.
What you have to do here to address logical record locking is to be able to uniquely identify the client that is locking the current record, and make sure that the same client is unlocking the record. As you have seen from the other thread that a static HashMap (or a WeakHashMap to be more specific) is the structure that holds the locking client's identity and the record being locked. Since the RMI based connection factory design guarantees a unique instance of the Data class for each client, it is the most natural client-identifier (Ok if you want to think of it as a Cookie) that you can have.
That is all that I am saying.
Hope this helps.
Bharat

[Rick Lu]

That's what I want to know.
Thank you so much, Bharat.
Rick

[Dushy Inguva]

Bharat,
I was under the impression that the Data class is a singleton which is shared by all the clients. For the clients to have unique Data classes, the only way i can think of is to
1. make Data it implement a remote interface
2. Lookup to the server
3. Call a factory method which creates a fresh instance of the Data class for a client and returns it (Since it is remote - pass by reference)
Lemme know if i'm speaking greek....
Dushy

[Bharat Ruparel]

Hello Dushyanth,
You have the right idea. A good way to guarantee unique instances of the Data class is by using the "Connection Factory" pattern in RMI driven solution. You can search on the forum for Connetion Factory to understand how this is done.
Regards.
Bharat