Local Adapter Issue

[Daniel Simpson]

Hi, I had a question about a local adapter issue. I already made a remote adapter for networking, but I am having trouble with my local adapter. Since my local adapter does not use any sort of locking, I can't decide whether I should implement the DB interface or not. I could implement the DB interface and not implement the lock methods or I had another idea. I could use a HAS-A instance and have a Data object that calls all of the methods except the ones that need locking. Then I could just write a new method for update. My problem is, if I took this approach, I need access to things such as the Data class's variables. Is there any way to do this besides make an inner class?
[ December 20, 2004: Message edited by: Daniel Simpson ]

[peter wooster]

Originally posted by Daniel Simpson:
Hi, I had a question about a local adapter issue. I already made a remote adapter for networking, but I am having trouble with my local adapter. Since my local adapter does not use any sort of locking, I can't decide whether I should implement the DB interface or not. I could implement the DB interface and not implement the lock methods or I had another idea. I could use a HAS-A instance and have a Data object that calls all of the methods except the ones that need locking. Then I could just write a new method for update. My problem is, if I took this approach, I need access to things such as the Data class's variables. Is there any way to do this besides make an inner class?

[ December 20, 2004: Message edited by: Daniel Simpson ]

Why not use the DB interface as is and use a null Lock Manager that simply does nothing but return a cookie for lock, true for checkCookie and nothing at all for unlock.

Or just use the standard locking methods, they will run very quickly if they only have the local client.

[Paula Decker]

I agree with Peter. I thought too about making the local interface contain different methods than the remote (DB interface), but wouldn't the UI then have to change its code when using local vs. remote? Even if the lock/unlock methods do nothing in the local implementation, I think its worth it to expose the same interface locally and remotely.

Am I right in thinking that there is no need to lock the db in local mode? The only case I can think of is if the UI is multithreaded. I'm planning on a single-threaded UI.

[Daniel Simpson]

This is from my doc:

You may assume that at any moment, at most one program is accessing the database file; therefore your locking system only needs to be concerned with multiple concurrent clients of your server.

So if I took the advice of using the exact same interface, would I be violating anything above? Although it does not explicitly say must, I wonder if this is some sort of implicit must. I am not using a Lock Manager in my application. But if I were to use the same interface as networking, then I would just pass in null or zero values where needed? Am I on the right track?

[Andy Zhu]

In my instruction, it says I can assume one and only one program access the physical file. It also REQUIRES the local client will have the same db server codes as networking one. It means except the rmi/socket codes, you don't view your clients differently. Furthermore, the assumption ensures little penalty for using locking in the local mode. We only consider one thread in standalone. In networking, the multithreads are created thru your socket code/RMI server.

So in my DBConnection, I have two static methods: getRemote and getLocal, both return DBClient, an interface of business logic wraps around data access layer. I don't know if this concurs with Max' book. Anyway, I think Max book should have a topic covering it.

[Matt Sheehan.]

You may assume that at any moment, at most one program is accessing the database file; therefore your locking system only needs to be concerned with multiple concurrent clients of your server.

My doc says the same thing, but I did what Andy did and passed without being penalized for it.

Matt

[Paula Decker]

In my instruction, it says I can assume one and only one program access the physical file. It also REQUIRES the local client will have the same db server codes as networking one. It means except the rmi/socket codes, ...

I was headed in the same direction as Andy, but I reread the specifications for B&S:

Non-Networked Mode
...
Architecturally, this mode must use the database and GUI from the networked form, but must not use the network server code at all.

I think I can still use the same interface (so the UI doesn't change from local to remote), but the implementation will be different. I think this satisfies the requirement that the local application

must not use the network server code at all

Does this seem correct?

[Daniel Simpson]

So if I understand you correctly, Andy, I have a DBAdapter which HAS-A Data object. My Data object implements the given DB interface. Am I correct in doing this? Here is my next question, though, my code for the book method roughly looks like this:

long cookie = data.lock(recNo);
      //check value
      //update
      //unlock  

My question is, is this correct for networked mode? Shouldn't the server be calling these things and not the client via the book method? It's pretty late so I might not be thinking straight. Thanks for the help!

[Andy Zhu]

Hey, Mat and Paula: thanks for your encouraging reply. At least I know there are precedences that Sun Ok's the method. I wish I could done with documentation sooner. I am counting on the incoming holidays.

Daniel:
First I don't mix business logic with networking/connection. What I called the adapter is the business logic layer which handles high-level operations on database using the methods in access layer. This layer has nothing to do with any networking/location connection.

In the connection layer which I placed in rmi package, it has an object of DBClient which the adapter mentioned above implements. In this class, it provides two public methods one for networking connection, the other for local mode, both return DBClient interface type. So in the connection layer, I never touch the access layer directly. I think you'd better study Max's book and his sample project. It really helps. I agree someone said it needs updated. But the existing methodologies still apply.

[peter wooster]

Originally posted by Daniel Simpson:
So if I understand you correctly, Andy, I have a DBAdapter which HAS-A Data object. My Data object implements the given DB interface. Am I correct in doing this? Here is my next question, though, my code for the book method roughly looks like this:

long cookie = data.lock(recNo);
      //check value
      //update
      //unlock  

My question is, is this correct for networked mode? Shouldn't the server be calling these things and not the client via the book method? It's pretty late so I might not be thinking straight. Thanks for the help!

The server could call those things, there has been a lot of discussion of this, do a search for "thin client". Some of us believe that this is a violation of the specification, but people have passed doing it. I use the "rich" or "fat" client model where this occurs on the client and the DBAccess interface is available to the client.

Here's an overview of the classes I use:

gui.BookingModel
   - the model in the GUI's MVC pattern
   - has a DBAccess instance that is either a DataProxy or a Data object
 
rmi.DataProxy
   - has a DataAdapter instance
   - implements DBAccess and DataControl by re-adapting the DataAdapter
   - provides data access to a networked client
   - uses the Proxy pattern, ie. an adapter with the same interface 
 
rmi.DataAdapter
   - a Remote interface that provides all the functionality of DBAccess and DataControl and adds RemoteException
 
rmi.DataAdapterImpl
   - the server side implementation of DataAdapter, has a Data object
   - uses the object version of the Adapter pattern 
 
db.Data
   - implemtents the DBAccess interface and a DataControl interface
   - provides data access to the server and the stand alone client
   - completely compatible with the DataProxy.
 
db.DBAccess
   - the interface provided by Sun
 
db.DataControl
   - an interface that provides methods to connect and disconnect 
 
db.DatabaseFile
   - a singleton that provides low level file access and locking facilities to the Data objects

[Andy Zhu]

Hey, Peter: like your post. so you use fat client? I used thin client and didn't notice this is at the edge of infringing instruction. But I think in this project, the thin-client vs thick-client just has several lines difference (I think Anton has mentioned this in one of his posts). However, from the view of the real world project design, what do you think of the strategy? I still lean on thin client.

[peter wooster]

Originally posted by Andy Zhu:
Hey, Peter: like your post. so you use fat client? I used thin client and didn't notice this is at the edge of infringing instruction. But I think in this project, the thin-client vs thick-client just has several lines difference (I think Anton has mentioned this in one of his posts). However, from the view of the real world project design, what do you think of the strategy? I still lean on thin client.

I did my first iteration on this project using the thin client. Its a lot simpler than the fat client. Most of the locking issues are far easier to code and you expose far less across the network. In URLyBird, all you need to provide to the network client is book and search commands, and there is no need to adapt the DBAccess interface to allow RemoteException. It could be done with a few lines of code if you already have implemented the fat client, but you end up with a huge pile of redundant code.

Here's the statements in the spec that I (and other, including Andrew, if he hasn't changed his mind on this) use to justify the fat client:

The main architecture of the application must be a traditional client-server system. There are three key parts: the server-side data management system, the client-side GUI, and the network connection between the two.

- A traditional client-server is a two tier architecture.
- the server is described as a data management system, not a business tier or an application server.

Server

Required Interface

The provided interface is titled as the server's required interface, I interpret this as meaning that this interface must be provided to the client.

Your user interface should be designed with the expectation of future functionality enhancements, and it should establish a framework that will support this with minimal disruption to the users when this occurs.

The thin client does not do this. Any enhancement to the capabilities of the client would require modifications be made to the server and possibly all existing clients. With the fat client approach the server has all the functionality required to provide access to the data and thus an enhanced client can run concurrently with the older version of the client. I actually have several client programs that can access the same server. The maintenance and testing client allows all database actions, inuding locking a records and leaving it locked.

The "thin client" isn't really that thin, its more like less fat. A true thin client would know nothing of the server's business capabilities and would use a protocol such as HTTP to access the server. This is explicitly forbidden.

[Nikolay Petrov]

quote:
--------------------------------------------------------------------------------

Your user interface should be designed with the expectation of future functionality enhancements, and it should establish a framework that will support this with minimal disruption to the users when this occurs.

--------------------------------------------------------------------------------

The thin client does not do this. Any enhancement to the capabilities of the client would require modifications be made to the server and possibly all existing clients.

The requirement does state this but for GUI. As I understand it this part SUN are talking about GUI functional enhancements. The guys from URLyBird will need to hire a programmer in order to do these. So he could also do the modifications in GUI's facade.

With the fat client approach the server has all the functionality required to provide access to the data and thus an enhanced client can run concurrently with the older version of the client. I actually have several client programs that can access the same server. The maintenance and testing client allows all database actions, inuding locking a records and leaving it locked.

With this I'm totally agree on the other hand