Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

FBN - packaging + locking

 
Akshay Sharma
Ranch Hand
Posts: 42
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I am almost through with the FBN assignment.
There are a few queries :
1). I have the following dir structure
- suncertify
- common (part of suncertify)
- db (part of suncertify)
- server (part of suncertify)
- client (part of suncertify)
I intend to put common/db/server in server.jar
and comon/db/client in client.jar.
Do my skel/stub classes go in both
I think my stub should be a part of client.jar
and the skel should be a part of the server.jar
In this case would both the jars have the server directory structure
Then should I intend to create a final jar with client.jar , server.jar , design doc etc etc.
Pls advise???
2). Pls through some light on the locking funda.
I have made the Data class a Singleton and then
I have a hashmap in it which is used to check whether a record is locked or not.
I dont see the need to maintain the client ids in the hashmap.
[ July 13, 2003: Message edited by: Akshay Sharma ]
 
Andrew Monkhouse
author and jackaroo
Marshal Commander
Pie
Posts: 12014
220
C++ Firefox Browser IntelliJ IDE Java Mac Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Akshay
Welcome to JavaRanch
Do my skel/stub classes go in both

Put your stub classes in both.
I think my stub should be a part of client.jar
and the skel should be a part of the server.jar

If you don't have the stub files in the server.jar, you may get a complaint when you try and bind your code that the rmiregistry cannot unbundle your stub files (or something like that - sorry don't remember the exact wording). You could try it without the stub files in the server package, and if you do get the exception, then you know what the problem is - always a good way to learn
Do you need skeleton classes? They were only needed for JDK 1.1. Take a look at the -1.2 option to rmic - if you use it you will not have skeletons created.
In this case would both the jars have the server directory structure

Yes.
Then should I intend to create a final jar with client.jar , server.jar , design doc etc etc.

Yes - you should have instructions on what should be in the final jar file in your instructions.html file. See the section marked "Deliverables".
When you go to upload this final jar file, you will receive instructions on what the name of the final jar file must be.
2). Pls through some light on the locking funda.
I have made the Data class a Singleton and then
I have a hashmap in it which is used to check whether a record is locked or not.
I dont see the need to maintain the client ids in the hashmap.

I am curious - normally people use the map because it can map the record locked to the client locking it. If you are not tracking the client id, then what is in your map? (That is, why aren't you using a set or a list?).
Are you tracking ownership of locks somewhere else? So that a client cannot unlock a record that they have not locked?
Regards, Andrew
 
Andrew Monkhouse
author and jackaroo
Marshal Commander
Pie
Posts: 12014
220
C++ Firefox Browser IntelliJ IDE Java Mac Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Akshay
Also, when you said that you have made the Data class a Singleton - do you mean that literally: that you have changed the constructors to private constructors and created a getData() method, or have you simply ensured that there is only one instance of the Data class in your application?
Regards, Andrew
 
Akshay Sharma
Ranch Hand
Posts: 42
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Andrew,
First of all thanks for a detailed reply on packaging.
I have made the Data class a singleton by making the constructor privateand using a getData static method.
In the hashmap I am simply storing the record number and a flag (Y/N) specifying whether the record is locked or not.
Rgds
Akshay
 
Andrew Monkhouse
author and jackaroo
Marshal Commander
Pie
Posts: 12014
220
C++ Firefox Browser IntelliJ IDE Java Mac Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Akshay
I have made the Data class a singleton by making the constructor privateand using a getData static method.

I don't believe this is a good idea. If there are any other programs that use the Data class then they will no longer be able to do so.
I know this is a bit academic - but consider if the client had already written a reporting program which used the Data class? Or if they had written a program to dump all the records into the database that we were given? In either case, they might not see the need to tell us that they had done so.
There is a comment in the instructions that:
Three classes are in this package: Data, DataInfo, and FieldInfo. With the exception of three methods, noted below, these classes are complete

I take the expression "these classes are complete" to mean that we should not go changing them.
In the hashmap I am simply storing the record number and a flag (Y/N) specifying whether the record is locked or not.

What does this give you over having a simple array?
I am not saying that you are wrong with this. I just think that a HashMap is overkill for what you need here.
Are you tracking ownership of locks somewhere else? So that a client cannot unlock a record that they have not locked?
Regards, Andrew
 
Akshay Sharma
Ranch Hand
Posts: 42
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Andrew,
I think I should not have modified the Data class to make it a Singleton.
What I intend to do is a having a data structure having the record number and a flag to signify its status.
Now I intended that all clients must look up this and only this data structure.
But I missed the point of tracking users alongwith this.
Can you suggest me a way for doing this in a clean way.

Rgds
Akshay
 
Philippe Maquet
Bartender
Posts: 1872
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Akshay,
I like the Singleton idea because its a common and easy way to ensure that "things" you intend to share among multiple users are unique (a cache of last accessed records is such a typical thing you want to share, for efficiency purposes). Except that a database system is multi-table by common definition. So my preferences go to the Multiton pattern : a static HashMap stores you Data instances (key = database file name) and the static getData() method accepts a database file name as parameter.
I don't know your instructions, just that they are different of mine. But if your Data class cannot be changed, you may still wrap its access in some DataService class which will construct-if-needed/distribute-existing Data instances as well. Of course the provided Data constructor would stay public, but you may still document it.
(Andrew)I don't believe this is a good idea. If there are any other programs that use the Data class then they will no longer be able to do so.
I know this is a bit academic - but consider if the client had already written a reporting program which used the Data class? Or if they had written a program to dump all the records into the database that we were given? In either case, they might not see the need to tell us that they had done so.

Those programs will run in different JVMs, and if thre is still a public constructor, where is the issue ?
Akshay, for your locking issue, try a searchwith the words "lock" and "LockManager". It should help you fix it.
Cheers,
Philippe.
 
Jim Yingst
Wanderer
Sheriff
Posts: 18671
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Those programs will run in different JVMs, and if thre is still a public constructor, where is the issue ?
If there's still a public constructor, it's not really a singleton. Maybe it's being used as a singleton in the sense that no one is actually creating a second instance - but the possibility is there. Akshay said he (she? No idea) made the constructor private though.
And will they necessarily run in different JVMs? This isn't part of our requirements, but it's quite plausible to me that if there are other Java classes that have been written to work with the Data class, someone in the future might want to integrate the functionality of those other classes in with your code. Often this isn't too difficult to do, but if you've made Data a singleton (i.e. if you enforce enssumptin that there's only one instance) it can cut own on your available options.
Even if the programs are on separate JVMs - maybe someone else on another project has written a program to use the Data API but with multiple tables; one instance per table. Your manager asks if the other team can use your nice shiny Data implementation for this. Do you say
(a) Yes, but you'll have to modify it some, and the modified version will be incompatible with my original version and we'll have to maintain two separate version.
(b) Yes, let me make a few minor modifications to my class to support the new needs, and then both projects can use the same Data code in the future.
(c) Yes, you can do that now.
(d) No, go write your own, dammit. This one's mine.
While I might favor (d) , I think most managers would prefer to hear (c) or (b) in most cases. Even if the JVMs are separate, it's nice to not have too many different incompatible version of a class being used.
But I missed the point of tracking users alongwith this.
Can you suggest me a way for doing this in a clean way.

For a partial answer to this (how to identify a unique user), search for "ConnectionFactory" in this forum - that seems the most popular way to ID a user. You still need to figure out what to do with this info - how does it interact with your locking mechanisn? - but I'll skip that for now; I need to go do other stuff. Good luck.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic