• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

About LockManager

 
Jack Yang
Ranch Hand
Posts: 59
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Micheal,I wonder where you put the LockManager?Is in the RemoteDBAccessImpl?Is it a static variable or instance varible?I mean this:
public class RemoteDBAccessImpl extends........{
static LockManager lock;
or
LockManager lock;
.
.
.
}
Thank you
 
Nate Johnson
Ranch Hand
Posts: 301
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I cant say how Michael did it, but I have a LockManager class that the RemoteDataImpl uses. It has a map that holds locks (record_num, id) so that my locks can be identified by the client (you dont want other clients to unlock something that you locked).
 
Jack Yang
Ranch Hand
Posts: 59
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I know what you mean Nate.Your param id is client id,right?But if you factory pattern,the RemoteAccessImpl will create many instances based on clients connection.The LockManager if just in the RemoteAccessImpl,not static,there also many instances LockManager based on RemoteAccessImpl.How can you know other's lock which record?
 
Sai Prasad
Ranch Hand
Posts: 560
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Use a Singleton LockManager and call LockManager.getInstance() whenever you need it from RemoteDataImpl.
 
John Smith
Ranch Hand
Posts: 2937
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Use a Singleton LockManager and call LockManager.getInstance() whenever you need it from RemoteDataImpl.

In my opinion, it is a bad design decision to make the lock manager a singleton. If just one more database table is added to the project, one would need to make multiple changes to accomodate the locking. In my design, the server creates multiple instances of lock manager, one for each database. So, if you have 50 clients using 5 databases, the server creates 50 remote objects representing the connections, 5 Data objects to reference the databases, and 5 lock managers to handle db access. With that design, you don't have to change a single line of code, no matter how many databases are handled. And the additional code that implements this design is only 10 lines of code in my server.
To make your server work with one table, sure you can make lock manager a singleton. However, to satisfy the requirement that your design must be easily extendible, think about lock manager conceptually, -- it is not a singleton. I got full score for my server design.
Eugene.
[ August 15, 2002: Message edited by: Eugene Kononov ]
 
Jack Yang
Ranch Hand
Posts: 59
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
But Sai,I still don't understand what you mean.Can you explain more details?
Thank you
 
Anonymous
Ranch Hand
Posts: 18944
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Eugene Kononov:

So, if you have 50 clients using 5 databases, the server creates 50 remote objects representing the connections, 5 Data objects to reference the databases, and 5 lock managers to handle db access. With that design, you don't have to change a single line of code, no matter how many databases are handled. And the additional code that implements this design is only 10 lines of code in my server.

The way I understand please correct me if I am wrong. For each Data object you have a corresponding lock manager. So in other words for each database you would have a data object and its corresponding Lock Manager. But what would your clients who are connected to "a" database ( using one Data object) do??? I mean they will have to share the Lock manager instance to correctly synchronize the updates on the record??
Thanks!
-Amish
 
John Smith
Ranch Hand
Posts: 2937
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

But what would your clients who are connected to "a" database ( using one Data object) do??? I mean they will have to share the Lock manager instance to correctly synchronize the updates on the record??

Of course the remote clients have to share the lock manager instance for a given database, there is no other way around it.
Eugene.
 
Guo RedBean
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Of course the remote clients have to share the lock manager instance for a given database, there is no other way around it.

Hi, ranchers, i read lots of posts and get great benifit from the site. thanks
Here is the question to Eugeue, if you use many lockMaganer instance, and the client want to finish one transaction across muti database, how did you implement the client? so, i just guess, do you need one MainLockManager?
 
Anonymous
Ranch Hand
Posts: 18944
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Eugene Kononov:

Of course the remote clients have to share the lock manager instance for a given database, there is no other way around it.
Eugene.

So in other words Eugene we do have to use singleton for a lock manager instance for a given database right?? Otherwise how else can we share instances??
-Amish
 
Anonymous
Ranch Hand
Posts: 18944
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Guo RedBean:

if you use many lockMaganer instance, and the client want to finish one transaction across muti database, how did you implement the client? so, i just guess, do you need one MainLockManager?

I do not think the assn requries us to think about this. What do ranchers think???
 
John Smith
Ranch Hand
Posts: 2937
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

So in other words Eugene we do have to use singleton for a lock manager instance for a given database right?? Otherwise how else can we share instances??

No, you don't need a singleton. To share an instance of the class, you create that instance and pass it to clients that need it. But if it is another table, you need to create another instance of lock manager and share that instance among the clients using the corresponding database.
Eugene.
[ August 15, 2002: Message edited by: Eugene Kononov ]
 
Sai Prasad
Ranch Hand
Posts: 560
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Here we go again about Singleton and LockManager. It is possible to have a Singleton LockManager and manage multiple tables in the future.
The LockManager doesn't keep any reference to the Data instance. For example when I invoke modify() method in the LockManager, the code looks like this:

It is not a bad design to have a Singleton LockManager. Moreover I lost only one point in the server side and I guess the accessor didn't think it was a bad design.
 
Michael Morris
Ranch Hand
Posts: 3451
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Jack,
I used a Builder Pattern to create composites for the different types of connections. I had three different types: LocalDataConnection, RemoteDataConnection and ControlDataConnecion. Using this scheme (and one of my selling points in the Design Choices document) it is a trivial matter to add new types of composites, such as FileDataConnection which could be used to insert or delete new files into the database from a file or possibly compact the database (remove the deleted records.)
So, back to the lock manager question. In the Builder Pattern, a director is used to build the appropriate composite. There is a base parent class of all builders which doesn't build anything so that it's children can override the appropriate "buildXXX" methods. In my implementation, ControlDataBuilder extended RemoteDataBuilder extended LocalDataBuilder extended the base parent DataBuilder. The buildLockManager method was first implemented in RemoteDataBuilder which maintained a protected static map of lock managers which were mapped to Data objects. The reason for this is that I had a DataFactory class that mapped Data objects to files even though there was never more than one Data object at a time in the server, the facilities were there to run any number of Data objects. So when the ConnectionDirector called buildLockManager on a RemoteDataBuilder, it checked the map to see if it already had a lock manager for the Data object (which had been previously built by buildData) and returned it if it were in the map or created a new lock manager, mapped it and returned it if it weren't.
Hope this helps,
Michael Morris
[ August 15, 2002: Message edited by: Michael Morris ]
 
John Smith
Ranch Hand
Posts: 2937
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

lockManager.modify(dbFileName, this, dataInfo, data);

Sai,
You are right, you can implement multiple databases with a singleton lock manager, so I'll take my previous comment back. I still think, though, that it is awkward to make lock manager a singleton. Also, in my implementation, lock manager doesn't need to know anything about dbfileName, dataInfo, or data (unlike in your code above). It seems to me that lock manager should be completely decoupled from Data and related classes, and the purpose of the lock manager is to lock records, not to modify data or serve as a proxy for modify() requests. Following simple refactoring rules, it is clear that the parameters in your modify() method refer to Data-related class, and therefore the entire method is best extracted from lock manager and moved to Data related class.
We obviously both passed the certification, and there are probably as many possible designs as there are people, but this discussion is interesting from the "Which design is better?" point of view.
Eugene.
[ August 15, 2002: Message edited by: Eugene Kononov ]
 
Jack Yang
Ranch Hand
Posts: 59
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thank you Michael,I know how to do.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic