This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
Hello all: My design is very similar to the one just discussed where I have a RemoteDataConnection class that is a remote object, but not bound to the RMI registry...so each client asks the connection factory in the registry for a remote connection and is issued a reference to a new RemoteDataConnection(data,lockManager) which lives on the server. (data and lockManager are instance variables that come from the connection factory). So, I am having two issues that I would like some insight into: 1) It has been mentioned that we don't need to change the method signatures for lock/unlock to include a "client id" (specifically if we use the connection per client model) Isn't true however that since there is only one locking instance for each data instance that there will need to be some adapter code to map the record number to the connection object? (like in a HashMap?) 2) It has also been mentioned that a business interface is a bad idea as it is not re-usable. In my design, the GUI speaks only to a business interface that defines methods like bookFlight, searchFlights, etc which in turn invoke the appropriate methods on a DataAccess interface (either local or remote). Is this against the requirements set forth by Sun? Should I remove this interface and go with a DataClient that implements DataAccess, but adds methods like bookFlight, searchFlight, etc? Any comments/suggestions would be appreciated! Thanks, Todd Harney
this against the requirements set forth by Sun? Should I remove this interface and go with a DataClient that implements DataAccess, but adds methods like bookFlight, searchFlight, etc?
No, I had a DataAccessFacade class which is the same thing. Only the facade isn't reusable, but to make another for other cases is easy, and actually easier than passing the interface with all the data class methods Even though you have one instance of LockManager, that class it to hold all the locks of all the clients. The Connection object that each client has can have it's own HashSet to track the locks that the client has, and only pass an unlock through to the Data class is that record is in their own HashSet. Mark
Mark, Did your facade class then implement the Data access interface? Or did it contain an instance variable of type DataAccess? Thanks for the help! Todd Harney PS - Regarding the lock manager class, you're saying that the lock manager itself has a mapping of record numbers to connection objects? And then each connection object has its own mapping as well? I guess I was not clear on that point. My remote data connection has a reference to the data class and the lock manager class. I thought I was just going to add a lock, let's say, for record 1 in the mapping with the connection object as the value...effectively mapping each locked record number to a presumably unique remote data connection object reference. Is that not correct..or is it misguided?
Joined: Jan 25, 2002
I think I see now... Each remote connection has its own set of locks for itself...this way we can guard against some other client trying to unlock a record that wasn't his, right? Let me know if I am way off base here. Thanks, Todd Harney
I’ve looked at a lot of different solutions, and in my humble opinion Aspose is the way to go. Here’s the link: http://aspose.com