Urgent, please help, reading remote Data

[kaedy_muro]

The specification says the client should include a class that implements the same public method as the suncertify.db.Data.
For local data, if the client just create data, read then close, it will be perfectly fine.
But if two clients read remote data from the server, what if the first client close the data while the second client still reading?
Or the server should have multiple data for different client?
Thanks in advance.

[Nigel Browne]

I think the answer to this lies with using a ConnectionFactory class. This will register the database with the server and then create connection objects. The connection objects can be closed without closing the registered database.

[Sai Prasad]

I have only Data instance per table. I also have a server side DataFactory which decides whether to open the db file or return the already opened db file.
You also need to think about synchronizing the calls from multiple clients accessing the same Data instance. You probably will have one remote object which implements the Data interface (Interface with all the methods in the Data class) per client.

[Adam Caldwell]

I implemented close() as closing the remote connection, not closing the database. It seems that having the "Data" going away whenever there are no clients and then coming back when there are clients is incredibly wasteful of resources.

[Sai Prasad]

Adam,
Good point. When you say "I implemented close() as closing the remote connection, not closing the database", do you mean that you set the client reference to the remote object null and call System.gc() at the client side?

[Peter den Haan]

Why call System.gc()? That is rarely, very rarely, necessary, and its effect is ill-defined anyway. Just let the goold old garbage collector do its job.
- Peter

[Adam Caldwell]

In mine (using Sockets & Object Serialization), close simply closed the ObjectStreams and the Socket. After that, any calls to the "RemoteData" object resulted in Exceptions (which is the behavior of the Data class should you call methods after close is called).

[Sai Prasad]

Peter,
I am not calling System.gc() or setting my remote reference to null. You are right about the garbage collector. Take a look at the link below:
RMI FAQ 1.4
It seems like, when the user closes the client application, calling System.gc() may cut down the waiting time for the RMI to call Unreferenced() from 15 minutes to anytime soon. I will do some test and let you know.

[Peter den Haan]

Originally posted by Sai Prasad:
I am not calling System.gc() or setting my remote reference to null. You are right about the garbage collector. Take a look at the link below [...]

Point taken, but with normal termination I would hope that the client will call DataInterface.close(), which in turn should clean up any resources held (such as any outstanding locks), rendering the whole point rather academic.
- Peter

[Uma Y]

Sai,
could you elaborate a little on this

I have only Data instance per table. I also have a server side DataFactory which decides whether to open the db file or return the already opened db file.
You also need to think about synchronizing the calls from multiple clients accessing the same Data instance. You probably will have one remote object which implements the Data interface (Interface with all the methods in the Data class) per client.

I dont understand in what scenario you return the already opened db file and when you would open the db file.
Also do you mean that multiple remote objects would share the same (one and only) Data instance.
Thanks in advance,
Uma

[Sai Prasad]

Uma,
I dont understand in what scenario you return the already opened db file and when you would open the db file.
Right now, if a client calls close() method, I am closing the database file. I probably will remove this code and release only the unreference locks. So I have a piece of code to check to see if the file is open or not before I make any call.
Also do you mean that multiple remote objects would share the same (one and only) Data instance
Yes. I mean for any particular table. If in the future you expand this design to include passenger table, then I will have one more Data instance just to serve the passenger table.
[ April 17, 2002: Message edited by: Sai Prasad ]

[Uma Y]

Thanks for your reply. One more doubt,
Do you have a collection object to store these various Data instances for different tables in the ConnectionFactory. I mean do you already have such kind of collection object or would you leave it for the future enhancement.

If in the future you expand this design to include passenger table, then I will have one more Data instance just to server the passenger table.

Thanks,
Uma

[Mark Spritzler]

Do you have a collection object to store these various Data instances

You will only create one instance of Data, and pass the reference to each Connection object.
Mark

[Uma Y]

Mark,
What I was asking was, I read in some of the posts that there should be different Data instances to cater for different tables. For each table there will be one Data instance (created based on the db file name). I suppose I am right till here.
I have two doubts:
1. How should the ConnectionFactory be coded for resuse so that there can be multiple Data instances each for a different table. Shouldn't i have a collection object which can store these various Data instances?
2. Also, when the client gets the ConnectionFactory object should it ask for a particular Data instance (say for passenger table or something else). If so how?
Thanks in advance,
Uma

[Richard denSeig]

Hi,
I interpreted the close() to mean that the database should shutdown...
To me, this is the place to use the LOCK DATABASE value of -1...if there are any locked records.
This will cause the application to block further lock requests and allow existing clients with lock time to finish...or time out if you use a lock timer...
If there are no locked records, just close the db.db file.
That's how I intrepreted this anyway...
-Richard

[Peter den Haan]

Originally posted by Richard denSeig:
I interpreted the close() to mean that the database should shutdown...

This is demonstrably wrong.
In a good OO design, there is no code that looks like

if (localMode) {
   db.close();
}

which effectively boils down to

if (db instanceof Data) {
   db.close();
}

Polymorphism is the OO architect's favourite mechanism to avoid this type of conditional behaviour.
Let's look at it from a different, less dogmatic angle. When you abstract the public methods in Data into an interface, you also abstract their semantics (meaning). DataInterface.close() does not mean "close the database file" simply because that's what the Data.close() does. If you think that, then you fail to get the point that an interface represents not only a code abstraction but, hand in hand with this, also a conceptual, semantic abstraction. In other words, just as an interface represents an abstract Java API rather than an implementation of that API, the meaning of the methods is expressed as an abstract operation rather than a specific action.
Down to earth. What does Data.close() do in an abstract sense? Yes, it closes the database file, but that's just the mechanics of it. What does it mean? Well, let's think. If you had indexing in your database, it would need to close the index file as well. If you had transactions, it would roll back any open transactions. If you used lock files to prevent a single database file from opened more than once, it would clean up those lock files. Data.close() cleans up all the database resources held.
That, then, is the semantics of DataInterface.close(): clean up all the database resources held on behalf of the caller. This is the abstract operation I referred to above. Because Data represents a single-user database, its actual action is to close the physical file as this file has been opened exclusively on behalf of the caller.
On the other hand, in the multi-user, networked case, RemoteData.close() probably means just cleaning up any locks held on behalf of that client. If you wish, you could in addition close the database file after the last client has closed its session. What it should not do is blindly close the database file. The meaning of DataInterface.close() is not clean up all the database resources held and clobber everyone else's data access in the process.
The client code provides a third perspective on the problem. With the design I'm suggesting here, it would simply say

db.close()

without caring what type of database "db" represents. This is how an interface should work! On a Java language level, when you are referring to an interface you can use any implementation of that interface (the "substitution principle"; it is true for classes as well). This should be equally true on a semantic level: if you have properly defined the meaning of your interface, you can use any implementation of it in exactly the same way. That can be true only if DataInterface.close() closes the file in a local implementation, but doesn't in a networked implementation.
- Peter
[ April 18, 2002: Message edited by: Peter den Haan ]

[Sai Prasad]

Originally posted by Uma Yarakaraju:

1. How should the ConnectionFactory be coded for resuse so that there can be multiple Data instances each for a different table. Shouldn't i have a collection object which can store these various Data instances?

yes. I have this collection in a server side DataFactory which is responsible to hold only one instance of Data for any given table

Originally posted by Uma Yarakaraju:

2. Also, when the client gets the ConnectionFactory object should it ask for a particular Data instance (say for passenger table or something else). If so how?
Thanks in advance,
Uma

yes. Server object/ConnectionFactory object can have a specific method to return a particular type of remote object

[Mark Spritzler]

Uma. Why add that adding functionality. Right now there is only one database, there are no other files, no need for multiple databases for different tables, and hence no need for a Collection of Data objects.
I just think that by putting that in the code, you are adding functionality that is not in the requirements. The client did not ask for that. So you are making arbitrary decisions for the client that might be completely unneccessary.
Plus it will save you time.
Mark
p.s. It seems to me that there are multiple conversations going on at the same time in this thread.

[Richard denSeig]

Hi Peter:
I am not sure what you are talking about:

This is demonstrably wrong.
In a good OO design, there is no code that looks like
code:
--------------------------------------------------------------------------------
if (localMode) { db.close();}
--------------------------------------------------------------------------------
which effectively boils down to
code:
--------------------------------------------------------------------------------
if (db instanceof Data) { db.close();}
--------------------------------------------------------------------------------
Polymorphism is the OO architect's favourite mechanism to avoid this type of conditional behaviour

In my design, I have no code like that you have above...
The point of the close() method is to shutdown the database...i.e. the method name close().
Since the binary datafile database we are working with (least mine) does not have a rollback or uncommit or any other nice things like that...I am doing my job when I check for locks...if there are locks, I wait till they are removed either by the successful completion of the client's "transaction" or, if the client died, by the expiration device.
Once there are no more locks...there is no reason not to close the database...in this assignment.
Yes, there could be "reading" clients...when the db shutsdown...that's OK, for this assignment.
As to your argument that the "semantics" of close have meaning beyond closing the db.file...no matter what the db is...a flat file or a GemStone O-O implementation...the code is specific to the db implementation...ie...if it were a GemStone db I would make calls to the GS.driver to work its magic...as this assignment uses a binary file for a db, then a call to db.close() seems fairly reasonable to me

-Richard

[Richard denSeig]

ummmm....I think I was wearing my stupid hat when I interpreted the close() to mean the whole database...
That is wrong-headed thinking ... mea culpa...
Actually, now that I am thinking more clearly, the exposed close() should only mean close the (single) client's data connection that invoked the method only! ...after all of this client's locks have been released...
My mistake...I had to read your (Peter's) comment a couple of times before I even realized what I had done...
-Richard...

[Uma Y]

Mark,
thanks for the reply. But still thinking:
Suppose today i code without Collection object (for various Data instance) and without Client specifying which Data instance to connect to.
Tomorrow if my code is to be reused for multiple databases, don't you think i will have to rewrite my client and modify my ConnectionFactory . Can i call my code reusable in that case?
To me itseems like i should atleast require the client to specify the database it wants to connect to. So that in future when the code has to be extended, the client doesnt have to change.
Do you think i might be penalized if I implement it.
Thanks,
Uma

[Peter den Haan]

Originally posted by Uma Yarakaraju:
Do you think i might be penalized if I implement it.

Depends on the effort. I implemented some basic support and, off the top of my head, was not penalised on design.
- Peter

[Sai Prasad]

I don't get it when people talk about "client specifies the database name to connect". May be I need some help with little explanation. Below is my implementation:
1) During client startup, a modal dialog shows up for the user to select the local or remote mode. This mode is set to the ClientDataFactory object which is responsible to give any gui controllers any Data object they need.
2) In our current requirement, there is only one table which I named as "ReservationTable" which has data in db.db. For every table, I will have a client proxy object. For ReservationTable, I have a client proxy object called "ReservationProxy" which also implements the IData interface implemented by the Data class
3) So if I want to do a flight search as supposed to passenger search, my flight search gui controller will ask the ClientDataFactory to return a ReservationProxy object. I think it is perfectly fine for the flight search gui controller to know about the class name of the client proxy object
4) In addition to this, I use fbn.properties file to store all (Currentlt only one) the table file names. I also have a FBNProperties class in the suncertify.common package to read/load fbn.properties file at the client and the server.
Tomorrow if you want to do passenger search, I will have a seperate client proxy object, my rmi server will have another create method to return me a passenger remote impl object and also I will have a singleton Data object representing Passenger table.
No need to pass any db file name in either client or server side.