It's not a secret anymore!*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes URLyBird: How to design network layer? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "URLyBird: How to design network layer?" Watch "URLyBird: How to design network layer?" New topic
Author

URLyBird: How to design network layer?

Sean Gildea
Ranch Hand

Joined: Jul 01, 2004
Posts: 81
I need some 2nd opinions please.

As of now, I have decided to extend Data.java with a DataAdapter class which will provide the RemoteException's I need in order to implement RMI.

My first of 2 question's is:

Should I design the DataAdapter.java class either as a single instance that serves many clients or as multiple instances, one per client? Since code clarity seems to be preferred to client efficiency, I believe having one instance will be slower but easier to code/understand. Am I on the right track?

My second question is:

Regarding the File I/O, I have decided to hit the db file each time a read or update is required, and consequentially , in order to do so with thread safety, I decided I should synchronize on the read and update methods. I wanted to see what people thought of this design decision?

Thanks!


SCJD, SCBCD, SCJP
Inuka Vincit
Ranch Hand

Joined: Aug 10, 2004
Posts: 175
for the first question you mean Data class right?
Inorder to take advantage of the locks requirement it is best to use one instance. If you did have one instance per user locks would be redundant.

Second question.

Many people read and write the file for every operation of data and yes you must synchronize. I used a cahce type implementation, that is only writes access the file. The only reason I chose this over useing file access is because I felt that using a Container class to perform searches made it easier for me to program and my code looked cleaner. Its all upto you. You seem to be on the right track.

Whatever you do I sugest that you think about it carefully and read some of the older threads to get a bigger picture of the possible problems you might hit with design descitions you take.


MCP (C# application dev 70-316) 860<br />SCJP 1.4 100% SCJD (URLyBird) 378<br />MAD 100% nuts
jiju ka
Ranch Hand

Joined: Oct 12, 2004
Posts: 306
Inuka,
So you are synchronizing on the reader or writer object?

What other options did you consider for locking. Can you please explain it.

I am currently thinking about implementing lock and unlock. I have some questions regarding that.

1. If you share a single instance of reader or writer, will performance become degraded. I will admit that the complexity is less and risk of dead lock is less thereby. Do we need to lose and open the reader or writer?

2. What is the bottle neck of having seperate reader/writer instances for each client thread - like using a connection pool or something?

3. Is the reader or writer analogous to connection in jdbc? If not what the analogy for connection here?

Jiju
Inuka Vincit
Ranch Hand

Joined: Aug 10, 2004
Posts: 175
Originally posted by jiju ka:
Inuka,
So you are synchronizing on the reader or writer object?

What other options did you consider for locking. Can you please explain it.

I am currently thinking about implementing lock and unlock. I have some questions regarding that.

1. If you share a single instance of reader or writer, will performance become degraded. I will admit that the complexity is less and risk of dead lock is less thereby. Do we need to lose and open the reader or writer?

2. What is the bottle neck of having seperate reader/writer instances for each client thread - like using a connection pool or something?

3. Is the reader or writer analogous to connection in jdbc? If not what the analogy for connection here?

Jiju




I am only synchronizing on the writer just before writing to the file. I read the file into a cache. The onlytime the file is involved is for update and create.

1. You have a single stream pair instance per customer? This make locks redundant doesnt it? A sperate reader and writer per client will make performance a bit better, but this is not a requirement. Furthermore if you do consider performance, then you have to account for all the extra memory ussage as well. The whole point of having locks is to have one Data object and handle the concurrent access.

2. I am assuming the bottlenext is at the OS level, the OS probably queues the read and write request. In my opinion having such a scheme is unneccary and like I said above makes the locks redundant because then you would have a single data object per custmer. The whole idea of locks on Data is to handle multiple concurrent requests cleanly?

3. Not realy sure its been a long long time since I have used jdbc. But our Data layer replaces the remote database(be it MySql, ODBC etc). From what I gathered from the requirements we implement a simplified database server using data and other wrapper classes(depending on your implementation).
jiju ka
Ranch Hand

Joined: Oct 12, 2004
Posts: 306
Thanks Inuka. I haven't thought much deep into locking mechanism.

My thoughts were to seperate the locking mechanism from rest of code.
So by seperating and configuring locking I can avoid locking records in stand alone mode.

One thing I was always curious was "why is everybody favouring a single writer instance" in order to attain concurrency. There are different locking terchniques. I couldn't find a discussion which was comparing the differences between each. I feel locking is very important and I am going to give as much as care to it as possible.
Inuka Vincit
Ranch Hand

Joined: Aug 10, 2004
Posts: 175
I am using a lock per record that allows concurrent writes to different records. Most people lock on the whole record locking container(they use a container of locking numbers). This meets the requirements 100% in that the waiting thread is only awakend when the lock for the specific record is released.

But what your talking about doesnt have anything do to with the locking scenario. Your talking about the actual file system which is the layer below the locks(and below record). I think you understand that the locking must be implemented as a singleton right? Once you do that anything below(you can do it anyways you please, ie multiple writing objects(doesnt realy take that much code, in my case 3lines more), single writing objects doesnt matter(if you do this you have to sync on this).

The thing I am saying is if you say you have a filestream pair per client, then your basically handling the the file creation above the Datalayer. This will also make the filestreams redundant since not everyobject is going to write all the time and also violates the DBMain since DBMain seems to infer that dealing with files is done bellow data. Dealing with multiple writes below the lock is totally different and you can do that without too much coding as well.

Maybe we are talking about the same thing. I hope I didnt confuse the inital poster too much
jiju ka
Ranch Hand

Joined: Oct 12, 2004
Posts: 306

Most people lock on the whole record locking container(they use a container of locking numbers).

That exactly what I had in mind when I wrote "why is everybody favouring a single writer instance". Some people are recommending locking on writer too. Record Level locking as you do is more effecient. To me locking the container or writer is same as file level locking.
 
Consider Paul's rocket mass heater.
 
subject: URLyBird: How to design network layer?
 
Similar Threads
Yes! Passed! 388/400
Two designs of locking mechanism
Finished my project here are my choices and I would like some feedback before I hand it in.
URLyBird 1.1.3 design questions
General design question