aspose file tools*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes NX: extends DB and fire listener Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of The Java EE 7 Tutorial Volume 1 or Volume 2 this week in the Java EE forum
or jQuery UI in Action in the JavaScript forum!
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "NX: extends DB and fire listener" Watch "NX: extends DB and fire listener" New topic
Author

NX: extends DB and fire listener

Davidd Smith
Ranch Hand

Joined: Jul 28, 2003
Posts: 62
Hi, everyone,
In some post in the forum I see some people said they use ConnectionFactory and their Connection interface extends Remote and DB interface which the Data class must implements to provide clients with accesses to database. But the methods in DB which are provided from the instruction do not throw RemoteException and the methods in Connection must throw RemoteException and the ConnectionImpl must extends UnicastRemoteObject, How can Connection extends DB or I missed something? If I must rewrite a Connection interface, copy all methods from DB to it and let they throws RemoteException, then if the DB changes and I want to provide the new feature, I must change the Connection interface. What should I do?
Another question, I want to use MVC, but because every client has its own connection, how to fire the databaseChangeListener for every client?
Regards,
Davidd
[ August 22, 2003: Message edited by: Davidd Smith ]
Andrew Monkhouse
author and jackaroo
Marshal Commander

Joined: Mar 28, 2003
Posts: 11430
    
  85

Hi Davidd,
If the interface Connection extends the interface DB, then you will have to copy the method signatures into Connection so that you can get them to throw RemoteException as well as their existing exceptions.
The major advantage of having Connection extend DB is that on the client side, both the local connection and the remote connection will be instances of DB.
Of course you do not need to do this. Some people doing the current assignment are exporting different methods in their remote interface than the methods detailed in the DB interface. One of the advantages of this is that the client will be decoupled from the database implementation. Another advantage is that since this remote interface is one of your design, you can have the same interface for both local and remote access.
Another question, I want to use MVC, but because every client has its own connection, how to fire the databaseChangeListener for every client?

In my opinion you do not need to do this. But, if you do want to do it, I suggest you look at the Observer-Observable pattern. This may give you some ideas. Possibly in combination with the JGuru RMI Tutorial's section on Client Side Callbacks.
Regards, Andrew


The Sun Certified Java Developer Exam with J2SE 5: paper version from Amazon, PDF from Apress, Online reference: Books 24x7 Personal blog
Davidd Smith
Ranch Hand

Joined: Jul 28, 2003
Posts: 62
Hi, Andrew,
Thank you for your direction. You always give me help. Because I have already do some works in MVC pattern, I want to make clear first whether I can still use it.
I have a Controller in the client in my former design. Now I have Connection act as a facade to provide all user logic to interact with database. But my Controllers now have no other use than only pass command from view to Connection. It seems I can abandon the Controller and let Connection act as a controller, is it suitable for a controllers in the server side? Then I need register the view as a model change listener in the Connection which is a Controller, and If I use a Static collection in Connection, I can still fire database change for every client. But is it still MVC? Is it a good design or just nondescript?
I remember you said in other thread that you call lock()/unlock() from client. If Connection provide the user logic, for example, bookingRoom(), is not it a good design to lock() and unlock() in this method? Thus the lock()/unlock() need not deal with client crash. And thus the Connection forces the order of lock() and unlock(), then we need not deal with the owner of the lock, am I go back to the begining of the discuss?
If the interface Connection extends the interface DB, then you will have to copy the method signatures into Connection so that you can get them to throw RemoteException...

Then Connection is a top lever interface and cannot extend DB because overriding method cannot throws Exception that overriden method does not throw, Can it?
regards
Davidd
[ August 23, 2003: Message edited by: Davidd Smith ]
Andrew Monkhouse
author and jackaroo
Marshal Commander

Joined: Mar 28, 2003
Posts: 11430
    
  85

Hi Davidd,
Regarding the use of MVC - this is not mandatory. It is hinted at in some of the instructions, but you may decide that it is overkill for your application. What you are proposing now is deviating far enough away from the concept of MVC that I do not believe you should still call it MVC.
You are talking about doing away with the current Controller because it adds little value at present. This then becomes a decision between implementing a pattern that may be useful later, and doing the simplest thing that currently works.
I remember you said in other thread that you call lock()/unlock() from client. If Connection provide the user logic, for example, bookingRoom(), is not it a good design to lock() and unlock() in this method? Thus the lock()/unlock() need not deal with client crash. And thus the Connection forces the order of lock() and unlock(), then we need not deal with the owner of the lock,

A number of other candidates are using similar arguments for their assignments.
The biggest objection would be future enhancments - any change to requirements will probably require a change to the server, requiring server downtime and changes to all clients. There are excellent reasons why you might want to ignore this issue - but I will leave you to try and think of them
The biggest thing here, though, is that you have to make a design decision as to how you develop your network interface. You have to weigh up the good points and the bad points of not only the choice you go with, but also the choice(s) you are rejecting. Then you should document this decision (point form is fine - you do not have to write a book on it ).
[Andrew] If the interface Connection extends the interface DB, then you will have to copy the method signatures into Connection so that you can get them to throw RemoteException...
[Davidd] Then Connection is a top lever interface and cannot extend DB because overriding method cannot throws Exception that overriden method does not throw, Can it?

True - sorry, I had forgotten which exceptions were thrown by the provided interface. So you won't be able to just extend the DB interface. This, I think is a major argument for having a different interface for your client to connect to the database.
Regards, Andrew
Davidd Smith
Ranch Hand

Joined: Jul 28, 2003
Posts: 62
Hi,
Andrew,
Thank you. I took you advice, let the Connection provide user logic and act as model, let controller pass user gesture, let view provide GUI and listen to change. It works well, do you think it is fine? It seems like three tier application?
I have still a few questions about lock.
When a client tries to lock a record, if the record has been locked, should the client just wait or check whether the client itself locked the record?
In Data class's update() or delete() method, I check whether the record is locked by others first. If I found the record do not be locked, what should I do, overwriting the record directly or locking the record first or throwing an Exception?
Recards
Davidd
Andrew Monkhouse
author and jackaroo
Marshal Commander

Joined: Mar 28, 2003
Posts: 11430
    
  85

Hi Davidd,
Your MVC sounds OK. I am not sure what you mean by three tier application. Normally a three tier application would exist in three separate machines, so the GUI on one machine, a middle tier doing (usually) business logic and calculations, and a third machine offering the database services.
When a client tries to lock a record, if the record has been locked, should the client just wait or check whether the client itself locked the record?

Verifying whether the current client has already locked the requested record is a good defensive practice, however even allowing a client to lock more than one record raises a whole lot of other issues (such as deadlock). I am not sure whether you want to get into that complexity.
In Data class's update() or delete() method, I check whether the record is locked by others first. If I found the record do not be locked, what should I do, overwriting the record directly or locking the record first or throwing an Exception?

I think you should not allow an update or a delete unless a lock for that particular record has already been granted. Check your method signatures and the comments provided with the interface - does it indicate an exception should be thrown if the user attempts to do something they shouldn't?
Regards, Andrew
Davidd Smith
Ranch Hand

Joined: Jul 28, 2003
Posts: 62
Hi,
Andrew,
thank you.

Verifying whether the current client has already locked the requested record is a good defensive practice, however even allowing a client to lock more than one record raises a whole lot of other issues (such as deadlock).

I only let a client book one record once, then will Verifying whether the current client has already locked the requested record raise other issues or need it verify?

I think you should not allow an update or a delete unless a lock for that particular record has already been granted. Check your method signatures and the comments provided with the interface - does it indicate an exception should be thrown if the user attempts to do something they shouldn't?

Below is my instructions:

I think I can throw a RecordNotFoundException when a not locked record is to be updated.
Do you think warpping a HashMap using Collections.synchronizedMap() is a good idea or it need not?
When a client lock a record and InteruptedException is catched, I just do nothing and keep it in while loop to seek the lock, is it ok? After locking a record, I think it need not to notifyAll(), is it right?
I found it is hard for a client to keep a reference to the key of a WeakHashMap in Data class if I do not want to break the oo principle.
Recards
Davidd
Andrew Monkhouse
author and jackaroo
Marshal Commander

Joined: Mar 28, 2003
Posts: 11430
    
  85

Hi Davidd,
I only let a client book one record once,

OK, that is good.
then will Verifying whether the current client has already locked the requested record raise other issues or need it verify?

This is an area you probably need to make a design decision in (and then document it )
If you don't verify whether the user has already locked the record, and then they try to lock the same record a second time, they will deadlock.
If you do verify whether the client has locked that particular record before, what is the correct action to take:
  • act as though the lock had been granted? But then what happens when they unlock the record? Which lock are they unlocking? Or do you count lock requests?
  • disallow the lock? But then what exception are you going to throw? Do the instructions for the lock method allow you to throw an exception (particularly the "block until lock granted clause")?


  • And this is just one part of the whole issue of how to handle the potential for one client to gain more than one simultaneous lock.
    As I said before: I don't think you really want to get into these complexities.
    Is it easier / safer to simply document that you are not catering for clients gaining simultaneous locks (possibly noting the issues that can arise from this stance)?
    Do you think warpping a HashMap using Collections.synchronizedMap() is a good idea or it need not?

    You do have to guard against the possibility of any thread accessing the map at the same time as any other thread is modifying it's structure. Depending on your implementation, wrapping the HashMap in the manner you suggested may be enough - but you have to decide whether it is enough based on your implementation.
    When a client lock a record and InteruptedException is catched, I just do nothing and keep it in while loop to seek the lock, is it ok?

    I think it is OK, but others believe that you should wrap it in another exception and re-throw it. You need to think about when your thread can be interrupted and what should happen if your thread does get interupted, keeping in mind your instructions.
    Regards, Andrew
    Davidd Smith
    Ranch Hand

    Joined: Jul 28, 2003
    Posts: 62
    Hi,
    Andrew
    thank you.
    After locking a record, I think it need not to notifyAll(), is it right?

    wrapping the HashMap in the manner you suggested may be enough - but you have to decide whether it is enough based on your implementation.

    I mean as I put all verifying and updating of the map into sychronized block, whether use Collections.synchronizedMap() is holding a candle to the sun?
    Recards
    Davidd
    Davidd Smith
    Ranch Hand

    Joined: Jul 28, 2003
    Posts: 62
    Hi, Andrew,
    My instruction said:

    The program must be able to work in a non-networked mode. In this mode, the database and GUI must run in the same VM and must perform no networking, must not use loopback networking, and must not involve the serialization of any objects when communicating between the GUI and database elements.
    Architecturally, this mode must use the database and GUI from the networked form, but must not use the network server code at all.
    Your choice of RMI or serialized objects will not affect your grade. In either case, the program must allow the user to specify the location of the database, and it must also accept an indication that a local database is to be used, in which case, the networking must be bypassed entirely.

    In my server mode, I use ConnectionFactory to generate the Connection. ConnectionImpl, which contains a Data instance, provides business logic such as booking and throws RemoteException implements Connection. In my local mode, I did not use class such as LocalInterface; I just use Connection interface and ConnectionImpl class directly to act as a data model. It does work. I think it is more maintainable and clearer, but I do not know whether it is suitable and whether it breaks the instructions "must not use the network server code at all."
    I provide alone mode only when "alone" is a command line argument. When a client mode starts, even if users input "localhost" when they choose the server, it runs in networked mode and there is loopback network in this case. Do you think I break the instructions?
    My instructions said:

    All configuration must be done via a GUI, and must be persistent between runs of the program.

    Every time when program runs, no matter it is server mode, client mode or alone mode, I always show a configuration form first. If there is no suncertify.properties file under the current working directory, users must fill the form. Else, the form is filled with the values used last time which fetched from suncertify.properties and users must push the "Enter" button to confirm it, user can also type in or choose a different value to update the value and accordingly update the properties file. Do you think it is consists with the instructions?
    Regards
    Davidd
    [ September 03, 2003: Message edited by: Davidd Smith ]
    Andrew Monkhouse
    author and jackaroo
    Marshal Commander

    Joined: Mar 28, 2003
    Posts: 11430
        
      85

    Hi Davidd,
    After locking a record, I think it need not to notifyAll(), is it right?

    You should not need to notify any other threads when you lock a record, but you may need to when you unlock the record.
    I mean as I put all verifying and updating of the map into sychronized block, whether use Collections.synchronizedMap() is holding a candle to the sun?

    Love the expression "candle to the sun" havent heard that for years
    More importantly though, is that the extra level of synchronization may be redundant, and may cause performance degradatation. The performance hit is very very small, but it is commonly reported to exist, so Sun recommends you avoid it.
    In my local mode, I [...] use Connection interface and ConnectionImpl class directly to act as a data model. Do you think I break the instructions?

    I think this is OK as far as the instructions are concerned.
    I think the instructions are more concerened with you forcing the rmiregistry or you socket server to run even when you are in local mode.
    Every time when program runs [...] I always show a configuration form first. [...] Do you think it is consists with the instructions?

    Yes, I think that is good.
    The only thing that might be a little more user friendly is if you can give default values if no properties file exists.
    Regards, Andrew
    Davidd Smith
    Ranch Hand

    Joined: Jul 28, 2003
    Posts: 62
    Hi,
    Andrew,

    quote:
    --------------------------------------------------------------------------------
    In my local mode, I [...] use Connection interface and ConnectionImpl class directly to act as a data model. Do you think I break the instructions?
    --------------------------------------------------------------------------------
    I think this is OK as far as the instructions are concerned.

    Because in local mode I use DBConnectionImpl, which extends UnicastRemoteObject and implements DBConnection that extends Remote, when I run it, the JVM asks me for the DBConnectionImpl_stub, only after I compile the DBConnectionImpl with rmic, the local mode runs normally. Is it correct local mode? Is it involves the serialization of objects?
    Regards
    Davidd
    [ September 16, 2003: Message edited by: Davidd Smith ]
    Andrew Monkhouse
    author and jackaroo
    Marshal Commander

    Joined: Mar 28, 2003
    Posts: 11430
        
      85

    Hi Davidd,
    You are not using serialization. You might be interested to take the Sun tutorial on Serialization so you can find out what serialization is about, and determine for yourself that you are not using it.
    I think you are OK with using the DBConnectionImpl. But if you wanted to be 100% sure, you could have a separate class for local connections.
    Regards, Andrew
    Davidd Smith
    Ranch Hand

    Joined: Jul 28, 2003
    Posts: 62
    Hi,
    Andrew,
    Thank you for your reply.
    If I have a separate class for local connections, should I copy all the codes from the server mode class DBConnectionImpl except RemoteException into the local class and do the same with their implemented interface?
    Regards
    Davidd
    Andrew Monkhouse
    author and jackaroo
    Marshal Commander

    Joined: Mar 28, 2003
    Posts: 11430
        
      85

    Hi Davidd,
    Personally I think all the logic / work should be in the class that handles local connections, and then the remote class is just a wrapper (Adapter pattern) for the local class.
    Regards, Andrew
     
    It is sorta covered in the JavaRanch Style Guide.
     
    subject: NX: extends DB and fire listener