• 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

Extending the database

 
Ranch Hand
Posts: 61
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,
In the spec it states that you can either modify the data class or extend it. What I have done is implement the criteriaSearch method int the data class, but the lock and unlock method's I implemented in the Remote object that each client receives. My question is, by implementing the unlock and lock methods in the remote class, I have not extended the data class and I have no enhanced the data class, how do I justify this in my design choice document, when you say why you choose to extend or enchance? Is my design flawed?
 
author
Posts: 3252
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The design is fine by me. The design was fine by my assessor. Of course, I did argue in my design documentation why things had to be done this way and no other --- I argued that locking is an artifact of networked operation, and that the responsibility of Data is to give access to a database file in local mode. As a consequence the Data class should implement the lock() and unlock() methods only as far as makes sense in local mode (it "implemented" them by validating the record number).
- Peter
 
Ranch Hand
Posts: 3404
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Peter,

locking is an artifact of networked operation, and that the responsibility of Data is to give access to a database file in local mode.


Do you see a problem with the following design:
In local mode , a Connection is also created and it's locking/unlocking capabilities re-used via instance of LockManager. The argument for this being that other business applications may run locally to the Data server. In this case, lock and unlock in the Data class have no implementation.
regards
 
Brian Blignaut
Ranch Hand
Posts: 61
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks for the reply Peter
 
Brian Blignaut
Ranch Hand
Posts: 61
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Not sure I really understand your question, but it sounds like something that is out the the assignment scope, which to me means don't do it as it just adds complexity that is not needed
 
HS Thomas
Ranch Hand
Posts: 3404
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Brian,
No, I don't think it is out of scope.
It's just another way of handling lock and unlock in local mode.
My question is why can't Connection and LockManager be re-used for local calls to Data?
OK, perhaps you need another class LocalConnection (to distinguish it from remote connections).
But this LocalConnection would acquire locks and unlocks from it's instance of LockManager and does its checks on the same shared HashMap/WeakHashMap as other Remote Connections.
Or is there a requirement in the assignment that the server is shutdown to remote connections when
Data is accessed locally ?
regards
 
Brian Blignaut
Ranch Hand
Posts: 61
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Ok, I see what you are saying, and no there is no requirement to stop the remote server when running in local mode, but remember that your remote server is going to have no idea what locks your local connection currently has as they are running in seperate VM's, therefore locking in local mode is not neccasary. Besides locking the file like Peter specified in a seperate thread which would only allow one instance of Data to connect to a data file, the only other way I can see of ensuring locks are maintained when two or more data classes access the same file is to write the lock to the actual data file, similar to the way the records are deleted, but this being said, you lock managers are still going to be out of sync so this is all pointless.
Or am I missing something?
 
HS Thomas
Ranch Hand
Posts: 3404
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks Brian.

your remote server is going to have no idea what locks your local connection currently has as they are running in seperate VM's


Perhaps it's my understanding of a local Connection that is at fault here.
I thought that a local connection meant that the Client would have been started in the same JVM as the Data server.
And in a remote connection , the Client gets started in a different JVM.
Is this wrong?
regards
[ February 07, 2003: Message edited by: HS Thomas ]
 
HS Thomas
Ranch Hand
Posts: 3404
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
And also , whats to stop any number of Clients starting locally (i.e. on the same JVM as the Data server).
For instance ,on my PC I can, from a MS-DOS command line , start a Client.Open another MSDOS window and start another Client.
Practically , on a very big server that has the JVM installed and has dedicated links from any number of terminals that can start Java clients.
My understanding is that these are local clients too.
Please ,someone, correct me if I am wrong !
[ February 07, 2003: Message edited by: HS Thomas ]
 
Brian Blignaut
Ranch Hand
Posts: 61
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Yes you are right in local mode, the client and the data class run in the same vm, whereas in remote mode, they run in different vm's. There is nothing to stop you starting a local client on the same machine as the network server, and yes then you cannot synchronize the locks. Remember because the local connection and and remote server are in different VM's they have different instances of the Lock Manager.
But this all out of the scope of the project so don't worry to much about it. Just put it in you documentation that you assumed that there will only be one instance of the data class talking to anyone data file.
Does this help?
 
Peter den Haan
author
Posts: 3252
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Having multiple processes accessing a single file concurrently is decidedly nontrivial. This is out of scope. Preventing such concurrent access is easier, but still out of scope. You may simply want to document that either exactly one client, or exactly one server, may be run against the database file.
In my design, the "Connection" you got in local mode was simply Data itself. Some like to insert an adapter here. There is certainly no requirement for local access to happen concurrently with networked access. It's only one of the two at any given time.
Does that help?
- Peter
 
HS Thomas
Ranch Hand
Posts: 3404
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Yes, thanks , Peter and Brian.
Obviously ,not a simple case of re-use as I thought it would be.
I'll state in the documentation that only one client is expected to run locally.
Thanks and regards
 
reply
    Bookmark Topic Watch Topic
  • New Topic