This week's book giveaway is in the Servlets forum.
We're giving away four copies of Murach's Java Servlets and JSP and have Joel Murach on-line!
See this thread for details.
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes Problem of having 2 different Lock Managers Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Murach's Java Servlets and JSP this week in the Servlets forum!
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "Problem of having 2 different Lock Managers" Watch "Problem of having 2 different Lock Managers" New topic
Author

Problem of having 2 different Lock Managers

Amit Kr Kumar
Ranch Hand

Joined: Feb 08, 2002
Posts: 100
Hi Mark, Peter and others
My Design is using a connectionfactory and each client has its own connection object. Design which is very much similar to Mark And Peter. Every Connection maintains a list of what all records it has locked. Vector of all the records locked is also contained by localLoclManager of Data.java
Now my problem is that i have RemoteLockmanager at RemoteDataAccessImpl. At the same time i have LocalLockManaget at Data.java. When a remote mode client calls a lock(n), the RemoteDataAccessImpl passes the request to RemoteLockManager which calls the lock method of Data.java and after that store the recno in the vector of locked records maintained by it
Is it correct ???
Maintaining Vector of records at 2 different places (Data.java and RemoteDataAccessImpl's lock managers) and managing them using different lock managers is my major worried
Another problem is that in Local Mode even locking is happening.
Pls Guide
Amit
[ June 14, 2002: Message edited by: Amit Kr Kumar ]
Mark Spritzler
ranger
Sheriff

Joined: Feb 05, 2001
Posts: 17249
    
    6

Every Connection maintains a list of what all records it has locked. Vector of all the records locked is also contained by localLoclManager of Data.java

Actually if you are using the LockManager design, your Connection object will not need to keep track of it's own locks. Unfortunately I did not use a LockManager, so some people get confused between my solution without a LockManager, and the one using the LockManager. The one using the LockManager is a better solution then mine.
I am a proponent of not having local mode lock records. However, it has not been determined if you inlcude locking in local mode whether or not you will lose points.
Either way you should only have one implementation of the LockManager irregardless of which mode the user is in. If you want to lock in local and in remote.
Mark


Perfect World Programming, LLC - Two Laptop Bag - Tube Organizer
How to Ask Questions the Smart Way FAQ
Jason Boutwell
Ranch Hand

Joined: Apr 02, 2002
Posts: 40
I just went through this same issue.
I decided not to manage locks at the local level.
I have one global LockManager, created by the ConnectionFactory, that manages remote locks.
Each remote Connection has a reference to the LockManager, and passes lock calls to it.
My lock methods in Data are empty and never called. The LockManager has no knowledge of the Data class.
It works quite well.
Amit Kr Kumar
Ranch Hand

Joined: Feb 08, 2002
Posts: 100
Thanks Mark and Jason for the quick reply
Jason u said that "My lock methods in Data are empty and never called". However the problem is that assignment instructions says that you have to either modify or extend the data class and implementy lock() and unlock() methods in it.
Another point is that if we have to leave the methods empty in Data.java then why sun provided those methods there.
Even if we leave it empty, in that case what should be the javadoc comment for them. May be "This method do nothing". Dont you think it will look very bad and voilate the contract between a interface and a class44.
Amit
Jason Boutwell
Ranch Hand

Joined: Apr 02, 2002
Posts: 40
You don't HAVE to leave those methods in Data empty. That's just the method I chose to use. Many other people have implemented lock() and unlock() in Data and passed the exam.
Each person must make his own design decisions regarding the implementation of locking, and explain those decisions in the design document.
I implemented lock() and unlock() in the remote Connection object, which implements the Data interface. So I am extending Data that way.
You should choose a method that makes your comfortable and that you are confident in.
Your mileage may vary.
Amit Kr Kumar
Ranch Hand

Joined: Feb 08, 2002
Posts: 100
Hi Jason
What abt the following statement in lock(int) of Data.java
lockManager.lock(myRecord, Thread.currentThread));
In Local mode we can delegate the action to Data.java.
However in Network Mode the Connection object will directly call Lock Manager as given below
lockManager.lock(myRecord, this);
In network mode the response will not be delegated to Data.java

Mark and Peter You are also requested to comment ?
Amit
Alan Strang
Greenhorn

Joined: Apr 11, 2002
Posts: 3
Amit
I have designed my lock/unlock in a similar way to yourself. Each of my RemoteData instances knows what records it has locked and can therefore call unlock(int record) only if it has previously locked the record. It then calls the lock/unlock methods in Data as defined by Sun. This in turn passes the call to an inner LockManager class which stores which records are locked by all clients.
Record locking is not implemented at the local level - my LocalData lock/unlock methods are empty.
I like this design because it allows locking to be done without modifying the signature of either methods. But, like you, I am not sure whether a two-stage locking mechanism is a good idea. That is, if a new class was written to provide multi-user access to Data and didn't implement the first stage, a client could theoretically unlock a record it hadn't locked. I suppose this could be a requirement to use Data in a multi-user environment.
Does anyone strongly believe this is not the way to go?


Alan Strang | SCJP | SCJD
Jason Boutwell
Ranch Hand

Joined: Apr 02, 2002
Posts: 40

What abt the following statement in lock(int) of Data.java
lockManager.lock(myRecord, Thread.currentThread));
In Local mode we can delegate the action to Data.java.
However in Network Mode the Connection object will directly call Lock Manager as given below
lockManager.lock(myRecord, this);
In network mode the response will not be delegated to Data.java

Sure, you could do that, but why implement any locking in local mode? Sure, some folks have come up with multithreaded ways in which a local client may need locking, but IMHO, that is out of the scope of the assignment. I don't believe that the re-use requirement is meant to account for such rare possibilities.
The locking method you describe for Network mode is identical to mine. However, I have NO locking code in Data.java. None. I left the methods in there because Sun put them there, and they aren't hurting anything.
Your mileage may vary.
Sai Prasad
Ranch Hand

Joined: Feb 25, 2002
Posts: 560
Originally posted by Amit Kr Kumar:
lockManager.lock(myRecord, Thread.currentThread));

It will not work. You cannot rely on RMI to create unique thread for each client.
You have only two options to use the LockManager:
1) Use it between the Connection object and Data and invoke lock/unlock/modify/delete methods in Data from the LockManager
Connection -> LockManager -> Data
or
2) Invoke the lock() method defined in the LockManager from the Connection object and then invoke the lock() method in Data from the *Connection* object.
Connection -> LockManager
Connection -> Data
Jason Boutwell
Ranch Hand

Joined: Apr 02, 2002
Posts: 40

I like this design because it allows locking to be done without modifying the signature of either methods.

You don't have to change the sigs. The remote object has a lock(int) call, which delegates to the global lock manager's lock(this, int). 'this' serves as the client identity.
I don't see any reason to have multiple levels of locking. A single lock managment class can serve all locking needs, and can also be re-used by other classes.
In proper OO design, according to me, , a single class should serve a single purpose, and be as decoupled from its client classes as possible.
As always, your mileage may vary.
Alan Strang
Greenhorn

Joined: Apr 11, 2002
Posts: 3
Originally posted by Jason Boutwell:
[QB]
You don't have to change the sigs. The remote object has a lock(int) call, which delegates to the global lock manager's lock(this, int). 'this' serves as the client identity.
[QB]

Yes, this makes sense, and is close to one of my other ideas. I guess I just really wanted to come up with a solution that actually used the lock/unlock methods in Data, rather than having them left out of the locking mechanism altogether. But a seperate lock manager does seem the best way to do it.
Thanks for your advice,
Alan
Amit Kr Kumar
Ranch Hand

Joined: Feb 08, 2002
Posts: 100
Is there anybody who have passed SCJD and used the same design i.e.
Leaving the lock and unlock methods in Data.java blank and no locking in local mode
???

Amit
Sai Prasad
Ranch Hand

Joined: Feb 25, 2002
Posts: 560
Yes. I think Peter did it.
Mark Spritzler
ranger
Sheriff

Joined: Feb 05, 2001
Posts: 17249
    
    6

I had no locking in my local mode as it is not needed. But I had code in lock and unlock, and did not have a LockManager class. If I was to do it again, I would have a LockManager class, and no code in the lock or unlock of the Data class.
Mark
 
It is sorta covered in the JavaRanch Style Guide.
 
subject: Problem of having 2 different Lock Managers
 
Similar Threads
Please review my design decisions
Lockmanager as inner class
Design Opinion
Alternative Locking Design
How to Lock(-1)