File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes connectionFactory question Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Soft Skills this week in the Jobs Discussion forum!
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "connectionFactory question" Watch "connectionFactory question" New topic
Author

connectionFactory question

Aruna Raghavan
Ranch Hand

Joined: May 14, 2002
Posts: 194
Hi,
I have read through some of the threads in this forum that explain why a connectionFactory is needed. I also read opinions on why using static Data and LockManager objects is bad.
If there are multiple tables in the database, can't we have one Lockmanager for each? Then the lockmanager can be static on a per table basis in the Data class. The alternative would be to modify the lockManager to have multiple hashmaps for multiple tables. I guess the second approach would limit the changes to LockManager where as the first approach would need changes to the DataWrapper class that contains the Data and LockManager.
Am I on right track with this?
Thanks.


Aruna A. Raghavan<br />SCJP, SCJD, SCWCD
Mark Spritzler
ranger
Sheriff

Joined: Feb 05, 2001
Posts: 17260
    
    6

Well you can think about more databases later, but the assignemtn doesn't suggest that that is necessary or will occur in the future. So by assuming that there is only one Data class and not multiple, then you will make the assignment easier, without adding extra that won't get you extra points.
Mark


Perfect World Programming, LLC - Two Laptop Bag - Tube Organizer
How to Ask Questions the Smart Way FAQ
John Smith
Ranch Hand

Joined: Oct 08, 2001
Posts: 2937

Well you can think about more databases later, but the assignment doesn't suggest that that is necessary or will occur in the future. So by assuming that there is only one Data class and not multiple, then you will make the assignment easier, without adding extra that won't get you extra points.

I respectfully disagree with Mark on this issue. I think it is an implicit requirement that very little or no modification should be required to the code if another table is added to the database. Unlike server GUI and dealing with dead connections (which are just toys that add nothing to FBN reusability), the design that allows multiple database tables is a huge plus. The implementation of this is just another dozen lines of code, and if I were an assessor, I would expect it in there.
One of the main challenges in this assignment is to distinguish between the niceties and nessecities (even if these nessecities are not explicitely mentioned in the requirements). Luckily, the answer to the challenge is in the requirement itself: your code should be easily reusable when new requirements (such as an obvious one for adding customers.db table) come in.
Eugene.
[ December 27, 2002: Message edited by: Eugene Kononov ]
Peter den Haan
author
Ranch Hand

Joined: Apr 20, 2000
Posts: 3252
Originally posted by Mark Spritzler:
Well you can think about more databases later, but the assignemtn doesn't suggest that that is necessary or will occur in the future.
My instructions explicitly stated that the database would be re-used in future projects. They also encourage coding the user interface with an eye on future enhancements -- which may well require another database table. It's not exactly an outlandish requirement, a second database table. Finally, the very fact that Data is a completely generic class that is not FBN-specific in any way should hammer the point home in case it wasn't clear yet.
So by assuming that there is only one Data class and not multiple, then you will make the assignment easier, without adding extra that won't get you extra points.
I beg to differ. The supplied Data class does not make this assumption anywhere and is no more complicated for it. Restricting your design to a single table brings questionable simplifications at best. In fact, most efforts to cripple the database server by introducing Singletons make the design more complicated, not less.
If you go with the ConnectionFactory approach, it is quite natural to instantiate both a Data and a LockManager in the ConnectionFactory constructor and assign them to (final) instance fields. Every Connection created by this factory can use either a factory reference or references to Data and LockManager (Aruna, you called it a DataWrapper rather than a Connection). The FBNServer class instantiates a ConnectionFactory for the local database file and binds it in the RMI registry. Another project may instantiate a dozen ConnectionFactory objects; the design allows it, or rather, is not deliberately crippled to prevent you from doing this. Did it complicate the design? No. Did it aid reusability? You bet. That's a no-brainer to me, but YMMV.
The above is not exactly the design I used, but it's about the simplest way to realise the ConnectionFactory approach.
- Peter
Aruna Raghavan
Ranch Hand

Joined: May 14, 2002
Posts: 194
Thanks much everyone, this is exactly how I understood it and coded it.
I tend to call the Connection class "DataWrapper" because in someways I tend to think of a real TCP/IP socket connection when someone says "Connection". To me, the actual connection is made when the client does the following:
ConnectionFactoryInterface airportData = (ConnectionFactoryInterface)Naming.lookup("rmi://localhost:2003/ConnectionFactoryImpl");
Mark Spritzler
ranger
Sheriff

Joined: Feb 05, 2001
Posts: 17260
    
    6

Yeah just listen to those other guys. They are right.
Mark
Aruna Raghavan
Ranch Hand

Joined: May 14, 2002
Posts: 194
Mark,
I agree with the XP principle of coding just the miminum required. Just in this case, it is not a whole lot of work to provide another level of indirection.
Please don't stop your comments, keep them coming.
Thanks,
Aruna.
Aruna Raghavan
Ranch Hand

Joined: May 14, 2002
Posts: 194
Hi,
Now I have it coded like this-
ConnectionFactoryInterface extends Remote
ConnectionFactoryImpl implements ConnectionFactoryInterface extends UnicastRemoteObject
ConnectionInterface extends Remote
ConnectionImpl implements ConnectionInterface extends UnicastRemoteObject

FBNDataInterface extends Remote
FBNDataImpl implements FBNDataInterface extends UnicastRemoteObject
FBNDataserver does the bind of ConnectionFactoryImpl.

Is it really necessary to have 3 sets of Remote objects? From my client, I call methods on ConnectionFactoryInterface, ConnectionInterface and LockManager.
Thanks,
Aruna.
Mark Spritzler
ranger
Sheriff

Joined: Feb 05, 2001
Posts: 17260
    
    6

I think that your
ConnectionInterface extends Remote
FBNDataInterface extends Remote
are really the same interfaces.
Mark
Aruna Raghavan
Ranch Hand

Joined: May 14, 2002
Posts: 194
Mark,
Yep, thanks for pointing that out.
Daniela Ch
Ranch Hand

Joined: Dec 13, 2002
Posts: 96
Originally posted by Eugene Kononov:

I respectfully disagree with Mark on this issue.
[ December 27, 2002: Message edited by: Eugene Kononov ]

Eugene, you often disagree with Mark on many issues
It is good, it always makes me think twice...
thanx
John Smith
Ranch Hand

Joined: Oct 08, 2001
Posts: 2937

Eugene, you often disagree with Mark on many issues

Not realy, it's just a few issues: MVC, gays in the military, legalization of drugs, and the right to bear arms.
Eugene.
HS Thomas
Ranch Hand

Joined: May 15, 2002
Posts: 3404
Peter,
could you please explain this in more detail
Another project may instantiate a dozen ConnectionFactory objects; the design allows it, or rather, is not deliberately crippled to prevent you from doing this. Did it complicate the design? No. Did it aid reusability? You bet. That's a no-brainer to me, but YMMV.

You seem to suggest to allow instantiating one ConnectionFactory object per Business Object / Table - the reuse being in the objects that are created subsequently rather than 1 ConnctionFactory being reused for all BO/Tables.
Am I right in thinking this?
Mark Spritzler
ranger
Sheriff

Joined: Feb 05, 2001
Posts: 17260
    
    6

the right to bear arms

Yes this has been our biggest disagreement. I think it should be right to arm bears.
Mark
Peter den Haan
author
Ranch Hand

Joined: Apr 20, 2000
Posts: 3252
Originally posted by HS Thomas:
You seem to suggest to allow instantiating one ConnectionFactory object per Business Object / Table - the reuse being in the objects that are created subsequently rather than 1 ConnctionFactory being reused for all BO/Tables.
Am I right in thinking this?
Actually -- but don't tell anyone -- I submitted something close to your second option, a connection factory with a connect(String tableName) method. It doesn't matter though. Either way, I would not want to make the ConnectionFactory a Singleton. When you parameterize the connect() method to take a table name, a ConnectionFactory would correspond roughly to a database schema, and making it a Singleton would mean removing the ability to have more than one schema for no good reason at all.
- Peter
[ January 03, 2003: Message edited by: Peter den Haan ]
HS Thomas
Ranch Hand

Joined: May 15, 2002
Posts: 3404
Thanks Peter,
I'm still trying to absorb this . So the first option would allow more than one database schema in a single JVM or many JVMs?

Thanks
Peter den Haan
author
Ranch Hand

Joined: Apr 20, 2000
Posts: 3252
Originally posted by HS Thomas:
I'm still trying to absorb this . So the first option would allow more than one database schema in a single JVM or many JVMs?
Let me rephrase. There are broadly two approaches you can take with your ConnectionFactory (or whatever you call it)
  • Each ConnectionFactory corresponds to exactly one Data instance, hence one table. You gain access to a table by looking it up in the RMI registry and getting a connection to it.
  • The ConnectionFactory.connect() method takes a table name. Each ConnectionFactory encapsulates an arbitrary number of Data instances; the factory can be said to correspond to a database schema. You would gain access to a table by looking up the schema in the RMI registry, and requesting a connection to one of the tables in the schema. The schemas in the RMI registry can live in one or more JVMs.
  • Both alternatives satisfies the assignment requirements; you should do whatever is easiest and/or comes most naturally to your design.
    In either case, you shouldn't go out of your way to limit the number of ConnectionFactory instances by enforcing a singleton pattern unless it significantly simplifies your design (which I don't think it will).
    - Peter
    HS Thomas
    Ranch Hand

    Joined: May 15, 2002
    Posts: 3404
    Thanks Peter,
    I have got it now.
    Two Questions.
    1. Using instances of ConnectionFactory connect(tableName1) and ConnectionFactory connect (tableName2) within a given schema at which point do I " connect" them ?
    Say I wanted to view a list of Customers on a given flight.
    Oh, I suppose, get the Flight details first , then connect to the FlightsBooked table,say,
    and call the getCustomers(Flight No) method.
    You are more than likely to have a CustomersImpl,
    FlightsImpl,AvailableSeatsImpl etc.
    But that's almost no work for the database , if your queries are limited to tables.
    No , wonder , there's such a fuss about Connection Pooling. Is this now a Networking headache rather than a Database one ?
    2. I was going to ask about schema's in other JVM's but that's not relevant anymore, I think.

    2.
    Peter den Haan
    author
    Ranch Hand

    Joined: Apr 20, 2000
    Posts: 3252
    Originally posted by HS Thomas:
    1. Using instances of ConnectionFactory connect(tableName1) and ConnectionFactory connect (tableName2) within a given schema at which point do I " connect" them ?
    Do the simplest thing. In this case that probably means you get a connection (i.e. a DataInterface implementation, either a local Data or a remote Connection) as soon as your application starts and release it only when the application quits.
    2. I was going to ask about schema's in other JVM's but that's not relevant anymore, I think.
    Probably not. Unless you do implement bizarre limitations in your code, the user of your networked database libary will be able to bind any number of ConnectionFactory objects in the RMI registry and created truly complicated databases living on multiple JVMs and multiple machines. But the Fly By Night Massively Parallel Database Cluster is probably out of scope for the assignment
    - Peter
    HS Thomas
    Ranch Hand

    Joined: May 15, 2002
    Posts: 3404
    Peter,
    Keep It Simple is the best advice I've had all week !
    Thanks.
    Actually , reviewing your last post, I think I haven't phrased the first Question well.
    ConnectionFactory connect(tableName1) gives my application access to table1's data.
    ConnectionFactory connect(tableName2) gives my application access to table2's data.
    By asking at which point I "connect" them (bad choice of phrase) I meant , is there an Object equivalent of a SQL table join ?
    Hope this is clearer !


    [ January 07, 2003: Message edited by: HS Thomas ]
    [ January 07, 2003: Message edited by: HS Thomas ]
    HS Thomas
    Ranch Hand

    Joined: May 15, 2002
    Posts: 3404
    Re-posting the previous edited post
    Peter den Haan
    author
    Ranch Hand

    Joined: Apr 20, 2000
    Posts: 3252
    Originally posted by HS Thomas:
    [...] is there an Object equivalent of a SQL table join?
    Not only is the the Fly By Night Massively Parallel Database Cluster is out of scope, I would submit that the Fly By Night Relational Database Management System is outside assignment scope as well, in the sense that the galactic core is outside the solar system
    Don't even think of going there. Joins are out.
    - Peter
    HS Thomas
    Ranch Hand

    Joined: May 15, 2002
    Posts: 3404
    Aaargh!
    That leaves the Fly By Night Associative Database Management SystemSentences and a myriad other Data Modelling systems.
    There are all these "things" that need to be related, associated, networked in order to do anything useful, and I bet there's one Simple way of doing it all , but the limiting scope of the assignment makes us stand and wait. :roll:
    [ January 08, 2003: Message edited by: HS Thomas ]
    [ January 08, 2003: Message edited by: HS Thomas ]
     
    I agree. Here's the link: http://aspose.com/file-tools
     
    subject: connectionFactory question