Win a copy of Re-engineering Legacy Software this week in the Refactoring forum
or Docker in Action in the Cloud/Virtualization forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

NX: Design review

 
Arjan Broer
Greenhorn
Posts: 20
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
For the URLyBird assignment i've come up with the following design. I was just wondering if i'm not over-complicating things.
I have a Data class implementing DBMain. This class handles all IO and is able to (un)lock records by a simple lock flag implementated in a Vector.
Because the String arrays are to close to the file structure, i implementated the column, schema, field and record classes.
I have a GenericColumn interface and a ColumnInfo class implementing the interface. The interface exposes getFieldName and getWidth.
The RecordSchema exposes getColumnCount and getColumnSchema. The column schema is an array of GenericColumn. SchemaInfo implements this interface and holds the array of columns.
The Field interface extends GenericColumn and adds getFieldValue and setFieldValue methods. The FieldInfo class implements this interface.
The Record class implements GenericRecord. This interface exposes functions to query the schema and field values. It also adds a unique id to the record.
The connection classes (remote and local) expose methods for retrieving records and update records (and all other functions that compare to DBMain) The difference with DBMain is that the connection class works with the Record schema i described above in stead of the string arrays. A huge advantage is that the schema validation is handeld by the record schema before the data is provided to the Data class. Also for building a client it is more intuitive to work with records in stead of string arrays.
Please tell me what you think of this design.
 
Vlad Rabkin
Ranch Hand
Posts: 555
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Arjan,
This class handles all IO and is able to (un)lock records by a simple lock flag implementated in a Vector.

What exactly do you store in Vector: only locks, or whole Record objects (cached database) containing lock flag as its attribute? Why is it Vector, but not an ArrayList?
I like your idea with Generic Columns and records, because I do the same
Best,
Vlad
 
Arjan Broer
Greenhorn
Posts: 20
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Vlad,
Thanks for your review.
The lock vector stores the recordID as an Integer. I implementated this as a Vector just because it is the first thing that came to mind. The conciderations for choosing Vector or ArrayList are not clear to me . Can you help me on that.
 
Andrew Monkhouse
author and jackaroo
Marshal Commander
Pie
Posts: 11854
185
C++ Firefox Browser IntelliJ IDE Java Mac Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Arjan
If all you store in your Vector is the record number, how do you ensure that only the user who locked the record is the one who can update it / delete it / unlock it?
As for choice between a Vector or an ArrayList: the Vector is internally synchronized. The ArrayList isnt. If you are synchronizing your calls to the Vector, then you have two levels of Synchronization.
Regards, Andrew
[ September 10, 2003: Message edited by: Andrew Monkhouse ]
 
Arjan Broer
Greenhorn
Posts: 20
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The locks in the data class are basicly flags on records and holds no owner data. I also have a LockManager that keeps track of the lock owners. A Connection class will call the lockmanager to create a lock on a record for a certain client. The lock manager then notifies the Data class of this lock.
The data class uses the lock to validate if an update can be done on the record. The lockmanager autorizes the operation for a client. So there is a slight difference in semantics of the Data lock and the LockManager lock.
Main reason for this is the DBMain interface. Data must implement this interface.
 
Vlad Rabkin
Ranch Hand
Posts: 555
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Arjan,
Why do you then a separate List and LockManager to keep track of locks?
You have record locks in the List and you have record locks with owners in LockManager. Why don't you want keep locks with their owners in Lockmanager and you only this class, instead of using an additional List?
Best,
Vlad
 
Arjan Broer
Greenhorn
Posts: 20
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Basicly because my Data class implements DBMain and DBMain contains lock(recno) and unlock(recno).
Now my connection Class contains lock(recno). This function calls the LockManager with lock(recno, this) where this is ofcource the clientID of type Object.
The DBMain (un)lock function is just to restrictive . Personaly i would prefer to leave out the lock and unlock in DBMain.
A concideration was to let the Connection class implement DBMain, but then i'm stuck with the String arrays for records .
Do you see any other solution?
 
Vlad Rabkin
Ranch Hand
Posts: 555
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Arjan,
What assignement do you prepare FBN or URLyBird? (I am interested in it to understand better your locking concept).
Your connection class is not actially obliged to implement DBMain interface.
Only your Data class must implement DBMain interface.
This should solve your problem with new method signature...
Best,
Vlad
 
Arjan Broer
Greenhorn
Posts: 20
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Vlad Rabkin:
What assignement do you prepare FBN or URLyBird? (I am interested in it to understand better your locking concept).

URLyBird
Originally posted by Vlad Rabkin:

Your connection class is not actially obliged to implement DBMain interface.
Only your Data class must implement DBMain interface.

Correct. My connection class acts as a proxy. So each client will have its own connection. Now the lockmanager stores the clientID (Object) as being the connection class. The connection class does NOT implement the DBMain interface.
My Data class implements the DBMain interface. And thus has an implementation of the (un)lock methods. The only reasonable functionality for these methods would be to set a flag on a record as being locked. (not actualy a flag, but an entery in the lock List)
So i solved the restrictive lock method of DBMain. Still this method has to be implemented on the Data class.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic