This week's book giveaway is in the Agile and Other Processes forum.
We're giving away four copies of The Little Book of Impediments (e-book only) and have Tom Perry on-line!
See this thread for details.
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

All data access methods need to be synchronized...

 
James Turner
Ranch Hand
Posts: 194
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi All,

In my view, reads should be able to occur simultaneously, but writes should be serialized and cannot occur when a read is taking place on the same record.

The thing is, if two reads are taking place at the same time on different records (this should be theoretically fine), there is only one file stream, which would mean, the two different reads would corrupt each other by trying to get information from different parts of the same file at the same time.

Synchronizing all data access methods is not something I want to do as it means all requests must occur in serial which basically defeats the point of concurrent access as the whole data class needs to be locked down for a simple read... which I think is pretty bad.

I can see that a better way would be that each thread maintain there own connection (stream) or a concept of a stream pool be maintained by the database.

Does anyone have any comments on this? Am i taking this too far? Or am I making sense?

Thanx for any comments or help...

James.


[ October 07, 2004: Message edited by: James Turner ]
[ October 07, 2004: Message edited by: James Turner ]
 
Mogens Nidding
Ranch Hand
Posts: 77
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
My requirements don't say that all data access methods need to be "synchronized". It would probably be more appropriate to say that all data access methods need to be thread safe. This does not rule out concurrent reads.

However, as you correctly say, multiple reads attempting to share the same file pointer concurrently is not a great idea. There are ways around this, however... But you should probably only implement concurrent reads if you can find a simple way to do it, since it is in no way a requirement for the exam. I'm sure others who have actually implemented concurrent reads will be able to help you out better than me :-).
 
James Turner
Ranch Hand
Posts: 194
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Nicky,

Thank you for your reply.

Is there anyone out there who knows a simple way of implementing a concurrent read??

Any help or comments is appreciated.

Thanx.

James.
 
Inuka Vincit
Ranch Hand
Posts: 175
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
My requirements actually say assume that only one user is accessing the database file at a time. As long as you read your file into a cache and then perform the operations of multiple read and writes using individual object locks per record you should be fine with the idea you have, but if you use RandomAccessFile directly you cant pull this off. If you read the file into a cache, you can actually do multiple writes to different records as well, you just have to sync when you update the file. Just make sure there is not lock on a record before you read, and figure out a way to do searches.

I was thinking about doing this kind of things as well, but then again why bother with the extra work if they wont give you extra points(its not that much more work realy). Its realy upto you if you think its a good design decision for future extensability do it.
[ October 07, 2004: Message edited by: Inuka Vincit ]
 
Robert Chisholm
Ranch Hand
Posts: 69
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It sounds like you're a candidate for NIO. Why don't you use that then?
 
James Turner
Ranch Hand
Posts: 194
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
We can't use NIO for this assignment.

Talk about limiting your options..!!

James.
[ October 08, 2004: Message edited by: James Turner ]
 
Mogens Nidding
Ranch Hand
Posts: 77
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I would say a good old RandomAccessFile has all we need and is easy to use. If the reason you want to use NIO is performance, then you are] probably going over the top :-). No matter how concurrently you try to read from a file, then unless you have a really fancy harddisk, the mechanical parts are probably going to be a bottleneck anyway. So, as Inuka suggests, a cache is a better option in terms of performance.

Implement caching if you want to learn something from it, but you don't have to since the SCJD isn't about performance. Your operating system or the RandomAccessFile implementation (which, by the way uses NIO internally in JDK 1.4) is going to do a little caching itself, so things should run smoothly enough.
 
Robert Chisholm
Ranch Hand
Posts: 69
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by James Turner:
We can't use NIO for this assignment.

Talk about limiting your options..!!

James.

[ October 08, 2004: Message edited by: James Turner ]


Heh... oh no! Here we go again with this topic... ah... do a search
 
peter wooster
Ranch Hand
Posts: 1033
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Nicky Bodentien:
I would say a good old RandomAccessFile has all we need and is easy to use. If the reason you want to use NIO is performance, then you are] probably going over the top :-). No matter how concurrently you try to read from a file, then unless you have a really fancy harddisk, the mechanical parts are probably going to be a bottleneck anyway. So, as Inuka suggests, a cache is a better option in terms of performance.

Implement caching if you want to learn something from it, but you don't have to since the SCJD isn't about performance. Your operating system or the RandomAccessFile implementation (which, by the way uses NIO internally in JDK 1.4) is going to do a little caching itself, so things should run smoothly enough.



The difference between NIO and RAF is that in NIO you can specify the file location as part of the read or write, in RAF its a seperate method call. Thus for RAF you must synchronize your low level I/O to ensure that the seek and read or write are done in a thread safe manner. NIO is thread safe, so you don't need the synch, but RAF is simpler, even including the synch.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic