Granny's Programming Pearls
"inside of every large program is a small program struggling to get out"
JavaRanch.com/granny.jsp
Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

LockManager as member of Data object

 
John Chien
Ranch Hand
Posts: 105
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,
By looking at the discussion, I found that almost
everybody implements LockManager to be something in parallel with Data.
My question is:
Can we make LockManager to be the data member of Data ?
If we only use only one database in a server, it seemingly to be the more natural way of handling locking.
Can anybody discuss the pro/con, advantage/disadvantage of including LockManager as or NOT as part of Data ?
Thanks,
John Chien
 
Mark Spritzler
ranger
Sheriff
Posts: 17278
6
IntelliJ IDE Mac Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Well, it is a question of, Does it harm or help, what about future design and use of Data class or LockManager class. You can always, easily get away with just creating an instance of LockManager in your server, and passing it the reference to the Data instance, and they will "Be Seperate".
If you choose either way, both need to be stated in your design.txt file and defended.
Good Luck
Mark
 
John Smith
Ranch Hand
Posts: 2937
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Can anybody discuss the pro/con, advantage/disadvantage of including LockManager as or NOT as part of Data

The less one class knows about the other class, the better. This concept is known as decoupling. You design will be much clearer and your implementation will be much more mainainable and extendible if your Data class doesn't know anything about the lock manager. That way, your lock manager can change independently of Data, and vise versa. There is also a notion of separation of responsibilities. Let your Data class provide the interface to database (read, modify, add, delete), and let your lock manager provide the interface to ensure the business requirement for multi-client access (lock/unlock). The lock manager has little to do with database, although it may seem otherwise. Notice that the integrity of the database is already ensured by the synchronized methods of Data.
Eugene.
 
John Chien
Ranch Hand
Posts: 105
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Mark & Eugene:
Thank you for the answer.
I am still not quite convinced.
1) Certainly, the LockManager is not an inner class of Data. It is a separate class. Thus, the change in LockManager does not necessary mean change in Data class.
2) The LockManager is instantiated at the time that the Data object is constructed. Thus, every client, that uses the same Data instances, uses the same instance of LockManager to do locking and unlocking. This is valid even if we use multiple database.
3) The Object Oriented paradigm encourages the use of containmentship. The containment of LockManager in Data is seemingly following the OO design principal.
4) Why is lock/unlock a business operation ?
If lock/unlock is a business operation, read, write, modify, delete can be considered as business operation too. Because they are all invoked by client based on their business decision. Read, write, modify, delete are actually database operation because they operate on database. The same is lock/unlock.
As I know, in today's commericial database, lock/unlock seems part of database operation. A database should have right to do the locking/unlocking on its own record.

My view point is not necessary correct. Please explain your view points more cleraly to me.

Thanks,
John Chien
 
Max Habibi
town drunk
( and author)
Sheriff
Posts: 4118
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi John,
Just as an FYI, your reasoningis just fine. There are, in fact, several valid ways to approach this problem, and you're on the right track.
M, author
The Sun Certified Java Developer Exam with J2SE 1.4
 
John Smith
Ranch Hand
Posts: 2937
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

1) Certainly, the LockManager is not an inner class of Data. It is a separate class. Thus, the change in LockManager does not necessary mean change in Data class.

In your design, Data class holds a reference to lock manager and invokes its methods. If LockManager method name or signature changes, your Data class has to change, too.

2) The LockManager is instantiated at the time that the Data object is constructed. Thus, every client, that uses the same Data instances, uses the same instance of LockManager to do locking and unlocking.

Fine, but you can accomplish the same without the dependency between Data and LockManager.

3) The Object Oriented paradigm encourages the use of containmentship. The containment of LockManager in Data is seemingly following the OO design principal.

OO also encourages loose coupling. If Data class can do its job without knowing anything about LockManager, it will most certainly be a better OO design than the one where LockManager is contained in Data.

4. [...] Read, write, modify, delete are actually database operation because they operate on database. The same is lock/unlock.

Suppose that instead of a flat db.db file, you had a commercial relational database where flight info is stored. Notice that you would still need to implement some sort of lock/unlock mechanism, although your RDBMS is full featured and it cost you a fortune. Your implementation of lock/unlock would be somewhere outside, -- it has nothing to do with the database functionality or integrity.
Eugene.
 
Max Habibi
town drunk
( and author)
Sheriff
Posts: 4118
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
John,
Before this issue become a bigger deal then it is, can you please explain to me, in a few sentences, what you think of when you think of a lock manager? I want to make sure everyone's on the same page.
ps - My advice is not to get caught up in the extensibility of this project. Code to the explicit specs, test carefully, and you'll fine.
All best,
M, author
The Sun Certified Java Developer Exam with J2SE 1.4
 
John Chien
Ranch Hand
Posts: 105
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Max:
I have already submitted my assignment.
If there is anything might get caught, it is too late.
In my understanding the LockManager is a class that is responsible for locking/unlocking of a database record in a database (NOT the database itself) requested by a client.
In term of this definition, I think the locking/unlocking of a database record is the ultmost right of a class that represents a database.
Although the LockManager itself can be designed as a generalized class that can be applied to any other application, in term of database, it is part of the database. It should not be something independent of database.
When Sun gaves us the assignment, it requires us to implement lock() and unlock() as the extension of the Data class. It means that Sun wants us to treat lock() and unlock() as part of database operations.
Centainly, we can design the Data extension by using a LockManager that is created parallelly to the Data instance. However, I can not see its real advantage. The Data still needs a reference to the LockManager so that it can do the locking/unlocking of database record. If we let the LockManager do the locking and unlocking of database record without Data knowing its reference, our design is really out of database control. It might cause any damage that the database has no knowledge of.
If the Data has the reference of the LockManager, it is really no diference by creating it in the Data constructor or outside.
However, if we create the LockManager instance manager as a indepent entity, we might have chance of getting into following situation:
The LockManager is accidently nulled out by the containing ConnectionFactory object while Data is still be used to do locking/unlocking.
Thanks,
John Chien
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic