ConnectionFactoryImpl contains instance of Data or RemoteDataObject?

[Panku Panchal]

Hi,
I'm really confused here. I'm right now working on my server side part and I want to know
1. ConnectionFactoryImpl contains instance of Data or RemoteDataObject?
2. Does this instance of Data passes "Database File" name or I have to give flexibility to user to select Database?

public ConnectionFactoryImpl extends UnicastRemoteObject implements ConnectionFactory {
private Data data;
private LockManager lockManager;

public ConnectionFactoryImpl()throws RemoteException{
super();
data = new Data("//DB filePath");
lockManager = new LockManager(); //my LockManager constuctor is empty.
}
public DataInterface getConnection() throws RemoteException{
return RemoteDataObject(data,lockManager);
}
}

Can you make any comments on my code and also provide me more information about the things I'm missing.
Also, in RemoteDataObject(data, lockManager) what should I write in the body of constructor?
I'm just writing,
this.data = data;
this.lockManager = lockManager;
thats all.
I need some more information and small hints to write code.
I've class LockManager, which will handle lock/unlock.
Please do comment, I really need help.

[S. Ganapathy]

Hi Panku,
I hope you are doing FBN assignment. I really don't know the requirements of that project. I am doing new assignment. I am given an db interface. I implemented in DBImpl class(this is not RMI class). I created a client interface. This inter face in implemented in RMI, as well as in standalone mode(DBAdapter in standalone, DBClientImpl in RMI). These classes simple call DBImpl implementation, and get the required functionality. I am following some guide lines in Max book. I seperated Locking functionality and provided in LockManager. DBImpl contains lockmanager instance.
I don't know much about design patterns. As a layman, I know, factory is one which produces more different customised things(according to the need) from the same factory(class). It may be more appropriate to name as adapter.
I have an iron box. I can plugin to power source in drawing room, or in bed room. So this is the adapter.
But do not expose the data interface directly to the client. This may not be the good idea. Any way options are open, and you may have different implementaion idea which may have equal or more weightage.
Regards,
Ganapathy.

[Andrew Monkhouse]

Hi Panku,

I'm really confused here

Yes, I think that is a requirement for doing this assignment

ConnectionFactoryImpl contains instance of Data or RemoteDataObject?

I think your code snippet is fine - the ConnectionFactoryImpl is creating the instance of the Data class and the LockManager, then passing them to RemoteDataObject. This should work fine.

Does this instance of Data passes "Database File" name or I have to give flexibility to user to select Database?

I think people have passed where they have stipulated that the database must be in directory 'x' relative to {the server jar file | the directory you start in}. As long as you do not make it a requirement that your database be in a specific directory (e.g. Dont force them to put the database in "c:\temp").
Personally I assume that the database is in the same directory as my server.jar file, but I also allow the user to override that location from the command line.
I dont think there is any need to have the networked client code specify the location of the database. I would even recommend against it - it is not very user friendly, and it is error prone. It is not user friendly because every user has to enter it, and it may be on a different architecture than the system the client is running (imagine a client working on MS Windows, with the server on Unix or VMS - the user would have to type in a pathname to the database which does not match any pathname they have seen before). It is error prone because ever user has to enter it - lots of chances for typos, plus what happens if two users enter completely different (but valid) paths to databases?

in RemoteDataObject(data, lockManager) what should I write in the body of constructor?
I'm just writing,
this.data = data;
this.lockManager = lockManager;
thats all.

That should be all you need in the constructor. I didnt have a lock manager, so I have one thing less in my constructor

I need some more information and small hints to write code.

Looks like you are doing fine.
Perhaps you should post a specific problem rather than having such an open ended question - we cannot give a complete solution to you, and I dont want to start talking about things which you have not thought about yourself yet.
I would assume RemoteDataObject also extends UnicastRemoteObject.
I would also assume RemoteDataObject has wrapper methods for each of the methods in the Data class - in most cases it will call them directly. It will just be the lock and unlock methods that will have extra work to do.
Regards, Andrew

[Panku Panchal]

Thank you Ganapathy and Andrew.
I've few questions ( I suppose this time they are close ended )

Personally I assume that the database is in the same directory as my server.jar file, but I also allow the user to override that location from the command line.

Can you please elaborate on this? How and why you allow user to override location of DB file?

I dont think there is any need to have the networked client code specify the location of the database. I would even recommend against it - it is not very user friendly, and it is error prone.

I agree with you, thank you.

Perhaps you should post a specific problem rather than having such an open ended question - we cannot give a complete solution to you, and I dont want to start talking about things which you have not thought about yourself yet.

I completely agree!!! my mistake but when confused , can't think of these high moral things.

would assume RemoteDataObject also extends UnicastRemoteObject

Yes, it does.

would also assume RemoteDataObject has wrapper methods for each of the methods in the Data class - in most cases it will call them directly.

Yes, RemoteDataObject has all Data methods, but can you again explain "in most cases it will call them directly"
Do you mean call Data methods from RemoteDataObject ? like data.modify()? Please don't think I'ma sking dumb questions but I just want to have clear understanding and also confirm my line of thinking with you guys( open ended again...Ooops!!!)
Waiting for your reply,
Panku

[Andrew Monkhouse]

Hi Panku,

Andrew: Personally I assume that the database is in the same directory as my server.jar file, but I also allow the user to override that location from the command line.
Panku: Can you please elaborate on this? How and why you allow user to override location of DB file?

How is easy: your ConnectionFactoryImpl currently hard codes the location of the database file path. All you need to do is allow the user to enter it on the command line and pass it to the ConnectionFactoryImpl which can then use the command line argument instead of the hard coded location.
Why? Too many years working purely on back end systems. The administrators always want to move things around. Typically this is done for backup purposes: the executable code changes rarely, so it can be put on a drive that doesnt get backed up often (if ever). The database changes rapidly, so it gets put onto a drive that gets backed up nightly. I have also worked at places that have another computer (not just drive) for documentation: they have the executables and data on high availabilty systems, and they have documentation and test systems on the cheapest computers they can find.
So, I got used to always allowing things to be moved. It is nicer as well.

Andrew: would also assume RemoteDataObject has wrapper methods for each of the methods in the Data class - in most cases it will call them directly.
PankuYes, RemoteDataObject has all Data methods, but can you again explain "in most cases it will call them directly"
Do you mean call Data methods from RemoteDataObject ? like data.modify()?

Yes, that is what I mean. The client code calls RemoteDataObject's find() method which calls Data's find() method.
However in some cases this may not be the case. You may decde you want to do some extra work that is not done in the Data method of the same name (for example in the lock() method).

Please don't think I'ma sking dumb questions but I just want to have clear understanding and also confirm my line of thinking with you guys( open ended again...Ooops!!!)

Haven't seen any dumb questions yet . In fact I cant remember seeing dumb questions in this forum - there are only questions by people who dont understand one or two aspects of their assignment, and I think most people end up in that situation (although with different problems).
Usually I go over to MD to get my daily dose of dumb questions. (Jim: you are right - I have become addicted :roll: )
Regards, Andrew

[Kevin Cao]

Panku,
Your code looks fine. Just some suggestions:
1. Since your RemoteDataImpl is a wraper class of Data, why create Data and Lockmanager instance in there? The purpose of ConnectionFactoryImpl is to create RemoteDataImpl.
2. I hard-code my database location in both cases, and it should be in the same directory as server.jar. Just want to keep things simple.
3. Also, you can provide a main class in ConnetionFactoryImpl to registry this object. And it will be your main class of your server.jar.
HTH,
Kevin Cao

[Panku Panchal]

Hi Andrew and Kevin,
Sorry for late reply, we had a long weekend so had gone to see some places and shopping!!!

How is easy: your ConnectionFactoryImpl currently hard codes the location of the database file path. All you need to do is allow the user to enter it on the command line and pass it to the ConnectionFactoryImpl which can then use the command line argument instead of the hard coded location.

Andrew, doens't this have a disadvanatage of every time typing the path to database and again if he typed wrong path ,Exception. Also, is it good to allow users know directory structure? Please do explain me . I really want to know the right way od selecting database?

Kevin Cao :
1. Since your RemoteDataImpl is a wraper class of Data, why create Data and Lockmanager instance in there? The purpose of ConnectionFactoryImpl is to create RemoteDataImpl

Yes, the purpose of ConnectionFactoryImpl is to create RemoteDataImpl, but I just want to create one instance of LockManager. Every user should use single instance of LockManager. Doesn't this is a requirement? If I create LockManager instance in RemoteDataImpl, every user will get his/her own instance of it and that is not what ir required. Please do comment on this.

3. Also, you can provide a main class in ConnetionFactoryImpl to registry this object. And it will be your main class of your server.jar.

Yes, that is what I'm doing , thank you.
Andrew, I agree with all your suggestions except unclear with one.
Waiting for comments...
Panku

[Panku Panchal]

Hi,
Also, I don't want user to mention whether he want to access database locally or remotelly. My system should identify it. How can I implement that?
Eagerly waiting for reply...
Panku

[Andrew Monkhouse]

Hi Panku,

Andrew: Personally I assume that the database is in the same directory as my server.jar file, but I also allow the user to override that location from the command line.
Panku Can you please elaborate on this? How and why you allow user to override location of DB file?[/i]
Andrew How is easy: your ConnectionFactoryImpl currently hard codes the location of the database file path. All you need to do is allow the user to enter it on the command line and pass it to the ConnectionFactoryImpl which can then use the command line argument instead of the hard coded location.
Panku doens't this have a disadvanatage of every time typing the path to database and again if he typed wrong path ,Exception

Ahhh, but as I said, I assume that the database is in the same directory as the server.jar file. So by default, the user does not have to type a path to the database. But if a power user (or administrator) really wants to, the system is flexible enough to allow it.

Panku Every user should use single instance of LockManager. Doesn't this is a requirement? If I create LockManager instance in RemoteDataImpl, every user will get his/her own instance of it and that is not what ir required.

Yes, if you are implementing a LockManager then you would only want one instance of it. There is nothing wrong with what you are doing, but an alternative to your way of coding though would be to use the Singleton pattern to ensure that any class can get the one and only instance of the LockManager.

Also, I don't want user to mention whether he want to access database locally or remotelly. My system should identify it. How can I implement that?

Grrrr, my instructions state:

The user interface should connect to the database using either a local or a network based connection according to user choice.

So I cannot take that choice away from them. Otherwise I like your idea.
On the other hand, I am submitting today, so it is just as well that I cant implement that - I dont want to start changing code today
How to do it should be relatively easy. Make sure your server registers with the RMI registry with something fairly unique (I concat my prometric ID and "FBNS_Bookings" to give me a unique RMI registration string).
Then all you need do is in your client program

check if RMI is running - if not, run locally

check if your service is running - if not run locally

run networked

Regards, Andrew
[ May 27, 2003: Message edited by: Andrew Monkhouse ]

[S. Ganapathy]

Hi Andrew, and Panku,
It is my pleasure find you discussion on this topic. Here I have few questions. I also started thinking to use factory pattern to provide local/remote connection. This is fairly a good idea of providing connection factory. Thanks to Panku.
Andrew, as you said, LockManager should be a singleton instance. I do agree with you. What about Data class (database implementation class, which implements read/write methods)? Is it a better idea to make it singleton too? If not, I have to share RandomAccessFile object (which I am using to read/write the data file) across many instances in a multi threaded environment, which is not fairly a good idea.
What about RMI string? Do we need to get unique string? Or simply mention in the ReadMe.txt file, to make sure no rmi object is using the RMi string which this application uses. I got an idea of using db cookie as rmi string for my server object. I already implemented db, and rmi. I need to do fre modifications to it. And testing in multi threaded environment is left, which I will do after I completed GUI implementation.
Please let me know your comments.
Thanks in advance.
Regards,
Ganapathy.

[Andrew Monkhouse]

Hi Ganapathy,
What about Data class ... Is it a better idea to make it singleton too?
I, like many others, have not bothered to make it a singleton. I leave it up to the JVM to manage multiple threads all doing reads and writes. However this does mean that the add method provided in the FBNS assignment cannot work correctly, and has to be modified in some way.
For FBNS, the Data class was already provided to us, and it was not a Singleton. So something somewhere has to be modified, but what, and where, is up to the coder
What about RMI string? Do we need to get unique string?
I think you do need to make a reasonable attempt to make the RMI string unique. Our instructions limit what we are are allowed to have as parameters, so we cannot let the user change it. And having something as generic as "FBNS" would be a definate no no in my opinion, as the company may want to do other RMI projects based on the success of this one, and we should not use the company name for a particular operation within the company.
Or simply mention in the ReadMe.txt file, to make sure no rmi object is using the RMi string which this application uses
I did both.
I got an idea of using db cookie as rmi string for my server object.
This could work.
I dont like it though, as the Data class is generic enough to handle any database, not just the airline bookings database, in which case the cookie would be the same in multiple databases.
Regards, Andrew
[ May 27, 2003: Message edited by: Andrew Monkhouse ]

[S. Ganapathy]

Hi Andrew,
What happens in your case if more than one thread is accessing different instances of database directly? Are you taking care of multiple instances? Why I am asking this question is read/write operations on files is very vulnerable. If you look at the logging frame work, this happens. Either one singleton instance is handling read/write operations, or a thread which handles read/write operations which does batch processing. This happens by queing messages in the writer thread.
This made me think about singleton instance. Another choice is that in RMI, we can declare Data as singleton, which is also reasonably good idea.
Waiting for your openion.
Regards,
Ganapathy.

[Andrew Monkhouse]

Hi Ganapathy,
For FBNS we were given an existing Data class which is not a singleton. I could have made it one, but I didnt want to change it like that.
The way I have it, each client indirectly gets their own Data class to work with the database file. Since the only writes are done on records that are locked, there should never be two threads both trying to write to the same section of the database at the same time.
I did test this, as I was worried about file positioning, and multiple classes having the same file open for read and write operations, and I have not been able to get it to fail.
I also saw plenty of posts in this forum where people had passed their exam with having multiple instances of the Data class, so I am not worried about this.
Regards, Andrew

[Max Habibi]

Hi Andrew,
If you want it to fail, try adding a record, even as you're modifying another.
M

[Panku Panchal]

Hi Andrew,
quote:
--------------------------------------------------------------------------------
The user interface should connect to the database using either a local or a network based connection according to user choice.
--------------------------------------------------------------------------------
Even my instructions tells me the same, but what I thought it silently telling us that user can login locally or remotelly, you should take care of his access to database in any case, but I never thought I'll have to ask user for that, 'cuz that is not a standard way of programming right?
What do you say? What if I implement the way I mentioned? Will I be penalized for that?
Waiting for your reply with "Ahhhh...s" and "Grrrrrs"
Panku
[ May 28, 2003: Message edited by: Panku Panchal ]

[Andrew Monkhouse]

Hi Max,
If you want it to fail, try adding a record, even as you're modifying another.
I take it you are telling me that this is an area where failure can hapen, even if it cant be proved in testing?
In which case having only the one copy of the Data class would be a requirement.
I already had to modify the add method so that it would work with multiple instances of the Data class.
I wrote a test application (one of many) which had two threads, one of which was decrementing an existing record 1 seat at a time for 100 seats, and the other thread was adding 100 new records from a base number entered at the command line. Running this caused no errors.
I also tried running two instances of this application simultaneously. Again, no errors (except when I forgot to set my modifyable record to have 200 seats )
If I hadnt already submitted, I would be tempted to go and change this though
Regards, Andrew

[Andrew Monkhouse]

Hi Panku,
Eeyaa , in real life I might agree with you - you would not want a user to be able to select local mode if network services are available.
However I am thinking about what the examiner may do ... they may decide to run the server early on in their testing, and just leave it running, while they do other things. So, while the server is running, they may want to run the client in local mode. It would be unusual, but if they are lazy to stop and start your server, it is possible.
So I dont think we can take that choice away from the user.
Perhaps a better way would be to give the user a simple confirmation type screen, where if you have detected the network is running, then default to networked mode, but allow them to change to local mode if they desire (and if they do, maybe popup a warning confirmation telling them that they may corrupt the database if they have a local and networked client running simultaneously.
Regards, Andrew

[S. Ganapathy]

Hi Andrew,
Where you are keeping locking code? At client side, or in the server(rmi/standalone)?
Are you taking care of client crashes if locking is provided at client side?
Regards,
Gnapathy.

[Andrew Monkhouse]

Hi Ganapathy,
My client explicitly does a lock, modify, and unlock, regardless of whether it is in local or networked mode.
The actual locks themselves are stored on the server. I did toy with the idea of having them on the client (I could even do that transparently with a serialized class ), but decided against it because I still needed to track locks on the server in case the client crashed while owning locks.
And yes, I do take care of client crashes (or even client exiting without releasing locks) ... in both cases, all locks owned by the now defunct client are released.
Regards, Andrew

[Max Habibi]

Originally posted by Andrew Monkhouse:
Hi Max,
If you want it to fail, try adding a record, even as you're modifying another.
I take it you are telling me that this is an area where failure can hapen, even if it cant be proved in testing?

No, it can fail in testing too. The point is that your tests, as I understand them, didn't deal with the size of the file changing from under you as you were modifying a given record. To support that, I think you'd either have to use the lock(-1) usage, or use a double monitor, or make the recordcount a static.
M

[Andrew Monkhouse]

Hi Max,
Yes, I made readcount a static. And I did test that my client which was connected before running the tests could see all the new records after the add was completed, simply by reselecting the search criteria (select "all, all, all": 24 matching records, run test, select "all, all, all": 224 matching records)
I did consider the -1 for adds, but I considered it overkill: as long as only one client can do an add at any given time, I shouldnt need to be so draconian.
I hadnt thought about a double monitor - I dont think I really want to though
Regards, Andrew

[Max Habibi]

Originally posted by Andrew Monkhouse:
Hi Max,
Yes, I made readcount a static.

The trick here, of course, is the the recordCount isn't decremented when a record is deleted, so the 'recordCount' is misleading. Worse, the directions state that the data class is in working order, except for the lock/unlock and some depreciated methods, so it's problematic to justify changing the code. All in all, I'm not sure there's an elegant solution here that doesn't require changing code that we've been asked not to change.

I did consider the -1 for adds, but I considered it overkill: as long as only one client can do an add at any given time, I shouldn't need to be so Draconian.

How are you enforcing that only one client adds or deletes a record? Also, how are you making sure that no one is modify a record while another client is adding a new record, or deleting an existing one? Are you only allowing a single client to access the db file at a time, even if they want to read different records?

I hadn't thought about a double monitor - I dont think I really want to though
Regards, Andrew

You're instincts are right on, IMO: I don't think you need one.
M

[Andrew Monkhouse]

Hi Max,
Sorry for the late reply - I went for a week's winter holiday with my girlfriend to the islands north of here - I could tell it was winter, the temperature was only 27C (80F)
Anyway, got my results back already (they appear to have been posted 2 days after I submitted!). I only lost 1 mark in general considerations, and 4 marks in server.
Given that my major losses were in the server, I guess I cannot recomend anyone follow my way of doing things. But just for completness, here's my answers to your questions:

How are you enforcing that only one client adds or deletes a record?

I modified the Data class, adding a static Object that acted as a synchronization gate for the add method. That way, only one instance of the Data class could do an add at once.
I know - this breaks the instructions that the Data class should be considered complete. Pure laziness on my part - I had finished coding, and was finalizing documentation when I realised I had a problem with multiple simultaneous adds, and I did not want to change it to a single instance of the Data class and redo all my testing and change documentation at that late stage.

Also, how are you making sure that no one is modify a record while another client is adding a new record, or deleting an existing one? Are you only allowing a single client to access the db file at a time, even if they want to read different records?

I did not consider this an issue. Modify and Delete both require locking the record in question. Trying to modify a record that was deleted caused an exception to be thrown which resulted in a dialog box appearing for the user giving an appropriate message. The only thing I had to guard against was two clients which were doing an add simultaneously, which I handled as mentioned previously. And of course, making sure the recordcount was static.
Regards, Andrew

[S. Ganapathy]

Hi Andrew,
Because the database is a file, I think, there should be only one instance of Data class (I mean singleton).
And the file object (ex RAF) is synchronized in the code, there is only one method(add/modify/delete) using the instance. This way we can control the db file.
So finally, we are allowing one client at a time will access the Data instance, and one method will get the file resource. Am i right Andrew, and MAX?
Regards,
Ganapathy.

[Andrew Monkhouse]

Hi Ganapathy,
I do agree with both Max and yourself that there should be only one instance of the Data class.
I had started with multiple copies of the Data class since my original design (in FBNS assignment) was using this as the key to who owned the lock (in your assignment you generate a cookie inside the lock method - I didnt have that option). Later I pulled this out, and had the ownership issue moved to a different class, unfortunately I did not think to go back and make the Data class a singleton. This caused me problems with the add method that I had to fix. But, as I said, I had done all my coding and testing and was loath to change the Data class to a singleton at the last minute. Perhaps I should have.
My code does work, however I do not recommend it, as I feel myself that it is not a good way of doing things.
Regards, Andrew

[S. Ganapathy]

Hi Andrew,
Thankyou for your suggestion.
There is an alternative approach in your case too, even if you allowed multiple instances of Data class. Make lock mechanism, a singleton, or provide only static methods, so that, multiple clients can not lock the same record. Hope, you provided this. This is the reason, your code didnot fail while testing.
Any way this is lesson to me, and I am learning this.
Thanks n Regards,
Ganapathy.