Once again about locking

[John Smith]

I am almost done with my assignment, but I am still very uncomfortable with my locking solution. On one hand, I want to comply with the requirement that locking is implemented in Data, but on the other hand, I don't want to lose points for locking in local mode. So I thought of this approach: implement locking in Data, but just do not call lock() and unlock() if it is local mode. That will require something like this in the facade (where bookFlight() method is implemented):

            if (data instanceof Data) {
                // do not lock
            }
            if (data instanceof RemoteDataImpl) {
                // lock
            }
  

Everything else is the same, -- RemoteDataImpl is an adaptor, and Data is an adaptee. So in networked mode, RemoteDataImpl will do its schtick to determine the client and subsequently call data.lock().
Now, I know that this "instanceof" code doesn't look particulary elegant, but this simple single if-statement (well, another one for unlock()) seems like a small price to pay for all the benefits:
-- Locking is implemented in Data
-- Signature of the method is not changed
-- Locking only occurs in networked mode
What do you guys think?
Eugene Kononov.

[BJ Grau]

Why not try writing a LocalDataImpl, which wraps Data. Have both LocalDataImpl and RemoteDataImpl implement the DataImpl interface which defines all the Data methods.
Your facade will call a factory, DataImplFactory, for example like this:
facade --> DataImplFactory.getDataImpl(int)
which will return a concrete implementation of DataImpl in the form of a LocalDataImpl or a RemoteDataImpl depending on the int you pass in. Your facade doesn't know what the concrete class is, only that it gets back a DataImpl interface.
In your RemoteDataImpl, lock and unlock remotely call the lock and unlock on Data.
In your LocalDataImpl, lock and unlock are empty.
This gives you flexibility later on because you can cleanly change the nature of how the local and remote implementations work without adding more if statements. The only if statement that ever gets called is in the factory.

-BJ
[ June 18, 2002: Message edited by: BJ Grau ]

[Sai Prasad]

BJ,
I like your approach. Even though I had the exact design in my submission, for some reason I called lock/unlock in the local mode and that might have contributed to point reduction in Genl Considerations. I am afraid that Eugene may have to modify his design more to suit your idea.
Eugene,
If you are not comfortable in changing your design, couple of "if" statements should be fine.
[ June 18, 2002: Message edited by: Sai Prasad ]

[John Smith]

BJ,
Thanks for your response. Yes, that sounds like a reasonable approach, too. The downside that I see is that all the public methods of Data will have to be implemented in two places, as opposed the other approach where RemoteData is an adaptor.
Eugene.

[Sai Prasad]

Eugene,
Isn't there a requirement to have a class at the client side to have all the public methods defined in the Data class? I think BJ's LocalDataImpl is designed to take care of this requirement.

[Jason Boutwell]

Why do you need a LocalDataImpl? Why not just use Data?
If you define an interface with all of Data's methods, and both Data and RemoteData implement it, then you don't need to use 'instanceof'. Let polymorphism handle it.

[Mark Spritzler]

BJ's is the way to go, that is exactly what I had in my design.
Do you have a LockManager class? I am liking the idea of not having any code in the lock or unlock methods of the Data class, and delegating it to the LockManager class.
Mark

[John Smith]

Why do you need a LocalDataImpl? Why not just use Data?

If you use Data, and your locking is implemented in that class, then the locking will happen in local mode. That's what we are trying to avoid. LocalDataImpl is another class which acts as a proxy for Data in local mode (if I understood BJ correctly). Again, I like that idea, except that the methods of Data will have to be defined in two places, actually four places, if you count the inteface: data interface, Data, LocalDataImpl, RemoteDataImpl.
Eugene.

[Jason Boutwell]

If you use Data, and your locking is implemented in that class, then the locking will happen in local mode. That's what we are trying to avoid.

But your locking should NOT be implemented in Data, IMHO. Locking should take place ONLY in RemoteDataImpl, which in my case delegates the functionality to a LockManager.

except that the methods of Data will have to be defined in two places, actually four places, if you count the inteface: data interface, Data, LocalDataImpl, RemoteDataImpl.

The methods are defined in one place, the Data interface.
They are implemented in two places, the local Data class and the RemoteDataImpl class.
I guess that my design differs because I have the Data class implementing the Database interface, rather than using a wrapper object for local calls.

[John Smith]

But your locking should NOT be implemented in Data, IMHO.

That's what some people argue. However, I don't want to take the risk of leaving the lock/unlock methods empty in Data, considering that the instructions implicitely ask you to implement it there, and the java docs for these methods in Data are explicitely describing these methods behaivior.
Eugene.

[BJ Grau]

Originally posted by Eugene Kononov:

Again, I like that idea, except that the methods of Data will have to be defined in two places, actually four places, if you count the inteface: data interface, Data, LocalDataImpl, RemoteDataImpl.
Eugene.

That's true, but from a maintenence perspective, changing the implementation of one of those methods in the future only requires you to change it in one place, Data. It won't be too bad unless you go changing the interface.
[ June 18, 2002: Message edited by: BJ Grau ]

[Matthew Comer]

I wish I had a bot that could auto-respond to any new threads on locking that showed up... This is such a common topic here.
There is a TON of misunderstanding on this forum about the requirements for locking in the assignment. Many of the experts here, including the forum moderators (who do a good job BTW) have stong opinions about "right" approach and sell their opinions as "correct" as it relates to the requirements.
Let me say this: I scored 153/155 and I DID IMPLEMENT LOCKING IN LOCAL MODE! The only two points I lost were on my database converter, which was a required item in earlier versions of the assignment (not any more though). The decision on local mode locking is a design choice. It boils down to this: Do you want a local client to be able to hold multiple connections to the db? Do you want these connections to cooperate like remote connections would? Do you want the db to be able to operate in "hybrid" mode, i.e. serving a local client as well as remote clients? (Yes, this is beyond the scope of the requirements, but mine could do it.)
Unless the person who graded my submission was wrong, I do not believe that implementing locking in local mode will cause you to lose any points. I believe that the correctness of your locking solution and your adherance to your design decisions about locking are what count. (This is my experience - caveat emptor).
BTW, I would be happy to provide my completed assignment to anyone on the forum (who I can tell from prior posts or who can otherwise prove to me that they are already SCJD2) as well as my score report to show that I am not making this up.
Matt
p.s. I want to say again that I think the forum experts provide endless amounts of good advice and help to those that need it. They are great. But I believe they are incorrect on this one.

[BJ Grau]

Matthew -
I agree with you. If you have a reason for allowing locking in local mode, or not allowing locking in local mode just give the reason and you will be fine. From what I've seen with this project there is no one right answer to anything. Just understand why you did or didn't do something and be able to explain it.
-BJ

[Jason Boutwell]

You say tom-AY-to. I say tom-AH-to.
Whatever gets the job done.

[Amit Kr Kumar]

Hi Matthew
Can you please put more light on your locking mechanism specially when a lock(..) method is called from a remote interface by REMOTE CLIENT ?
Did you used Any LockManager ?

Amit

[Matthew Comer]

Yes, I had a LockManager.
First, I had a business facade layer that the client communicated with, never directly to the db. This facade ran client-side when in remote mode. The facade layer used a Connection object to talk to the db - either a LocalConnection or a RemoteConnection. The "identity" of these Connection objects is what I used for locking, i.e. this is what I used for my client id.
Because I had locking in both local and remote mode, my Data class owned an instance of LockManager and delegated locking calls to it. Therefore, each Data (table) instance has it's own LockManager, which is as it should be.
The trick then becomes "how do I tell Data WHO is doing the lock, when the method signature for lock() and unlock() don't specify any such parameter?" You could add a Connection parameter to lock() and unlock(), but since I also decided to ENFORCE locking for create/delete/update record calls this means I would have needed to pass the connection id to these as well... Awkward. Instead, I "registered" the fact that a given thread was working on behalf of a given connection using a ThreadLocal-like mechanism (this was before ThreadLocal became well implemented as in 1.4. Today I would use ThreadLocal directly). NOTE - this does NOT imply that I assumed that RMI would use the same thread to service the same remote object every time. It won't! This registration of the Thread<->Connection relationship occured for each call, and was unregistered at the end of the call. This meant that any code anywhere in Data or it's helper class could always determine which connection was being serviced.
Matt

[Sai Prasad]

A simple solution would be to put the LockManager between the Connection object and the Data object and use the Connection object as the identifier.

[ravindra janapreddy]

I have implemented lock & unlock methods in LockManager class. It this approach wrong as per the assigment specifications?

[ravindra janapreddy]

The specification says :
Part of your assignment will be to enhance the Data class. You may do this by modification or subclassing, but you should document the approach and reason for your choice. You are required to implement the criteriaFind(String), lock(int) and unlock(int) methods:
This implies that implementation for lock, unlock and criteriaFind must be in Data class or deferred to its subclass

[Sai Prasad]

Originally posted by ravindra janapareddy:
I have implemented lock & unlock methods in LockManager class. It this approach wrong as per the assigment specifications?

No. It is preferrable to implement lock() and unlock() in the LockManager since you don't need to use these methods in the local mode.