• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Tests done on Data Class

 
Greenhorn
Posts: 17
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi guys, I have been told that the accessor will run automated tests on the Data class. However, I have a little problem over here. For my design, I have a factory class that is binded to the RMI registry. This class creates database session objects that are also remote objects, which means one unique session object per client. I want to make use of this uniqueness to control lockings to one lock per client. The issue I'm having now is that if a client wants to request for a lock, he needs to have already gotten the session object. However, if the Sun Microsystems accessor directly tests the Data class without going through the proper procedure first (i.e. launch the client GUI and let the controller class request for a session object), the lock method will refuse to grant the request, and as a result, he will not be able to execute mofify, delete etc. And that surely means all automated tests will fail. I may be failed on the spot.

Any suggestions here? Or am I just thinking too much? In the first place, is there even any truth that automated tests are done? If yes, I'm pretty sure I will not be the only one asking this question, right?
[ February 06, 2005: Message edited by: Stephen Loh ]
 
Ranch Hand
Posts: 1033
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I've heard on good authority, that automated tests are done by the accessors. My solution to this is to have the Data class implement DBAccess and Session and to make construction of a Data object be the activity that creates a session, destruction of a Data object will eventually end a session courtesy of finalize. I provide a disconnect method in Session that will explicity end a session.

When used remotely I define a DataProxy class that is substitutable for Data, ie. it has an identical public interface. Remote clients use DataProxy. Standalone clients, the server and anything the accessor would run use Data directly. This model means that the accessor doesn't need to know about the session methods and can use Data strictly through the DBAccess interface.
 
Stephen Loh
Greenhorn
Posts: 17
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I have thought of one solution, but I'm not sure if it is feasible. I register a DataFactory in the RMI registry, and in this factory, it creates unique instances of Data.

Since the instances of Data are unique, I can store all the locks that the client has acquired there. In the Data class, I can write a method to check for the lock list. However, for security measures, I will make the method private, so that the client cannot call it.

Is it feasible?
 
Stephen Loh
Greenhorn
Posts: 17
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Oh crap. I just realized my proposed solution won't work. If the accessor creates only one instance of the Data class, the accessor can only act as one client and not multiple clients. If I restrict to one lock per client, then I'm in trouble. If I don't, I risk deadlock.
 
peter wooster
Ranch Hand
Posts: 1033
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Stephen Loh:
Oh crap. I just realized my proposed solution won't work. If the accessor creates only one instance of the Data class, the accessor can only act as one client and not multiple clients. If I restrict to one lock per client, then I'm in trouble. If I don't, I risk deadlock.



I see nothing wrong with that design, just document that each client must have a seperate instance of the Data class.
 
Stephen Loh
Greenhorn
Posts: 17
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Yup, I agree that by right, there should be nothing wrong. That will mean that should the accessor create only one instance of the Data class, and I eventually decide to limit clients to one lock at a time, then all his automated tests will fail. During that time, will he actually resort to failing me on the spot and not even bother to read my documentation? I hope not!

At first I thought that the so called "software test" is merely checking that your JAR file conforms to the specs (number of folders, naming convention etc). Even if they do perform a check on the Data class, what I initially thought was that it only checks if you illegally modify the DB interface, and if your Data class really implements that interface. The reason why I thought an automated test is not possible is that everybody designs his application differently. What if the Data class relies on other classes to function correctly, and those classes can only be instantiated under certain conditions (e.g. client connection through the GUI). If an automated test really takes place, I can see that many people will be failed on the spot, because the accessor doesn't even know exactly how it works.

According to the specs I received:

The marking is done in three phases. First, software checks that overall structure and nomenclature conform to specification. Second the examiner runs the code ensuring that it functions correctly through the specified operations. If any automatic failures are noted at this stage, the marking process terminates and the assignment is failed.



My interpretation is that the so-called "overall structure and nomenclature" refers to your JAR file organization, naming conventions, your DB interface and your Data class. When they mentioned that the examiner runs the code, it probably means that they will actually invoke the JAR file and not perform automated testing.

If an automated test really takes place, then I think it is a little unfair, as nothing about that is mentioned in my specs.
[ February 07, 2005: Message edited by: Stephen Loh ]
 
Don't get me started about those stupid light bulbs.
reply
    Bookmark Topic Watch Topic
  • New Topic