B&S Any solution if I don't want methods in the Data class to be synchronized?

[Mingwei Jiang]

Although the instructions told me nothing regarding performance and synchronization, which means I can either choose to synchronize them or not to synchronize them, I'd like to know what's the better way to implement the Data class without synchronization.

In my mind, if I don't wanna do the synchronization and want a better performance. I will choose to have multiple RandomAccessFile instances managed in the Data instance with each serves a client request. Like when one RandomAccessFile instance is updating the record, another RandomAccessFile can also do the creation, deletion and updation of the record as long as they are not accessing the same record.

Is there anyone who has the same thoughts or better ones? For the exam alone, I will choose the synchronization solution, since the instructions didn't say anything about that and it's easier to implement. But as a learner, I'd like to know the sophisticated one, the one without synchronization.

[Mark Smyth]

Originally posted by Mingwei Jiang:
Although the instructions told me nothing regarding performance and synchronization, which means I can either choose to synchronize them or not to synchronize them, I'd like to know what's the better way to implement the Data class without synchronization.

In my mind, if I don't wanna do the synchronization and want a better performance. I will choose to have multiple RandomAccessFile instances managed in the Data instance with each serves a client request. Like when one RandomAccessFile instance is updating the record, another RandomAccessFile can also do the creation, deletion and updation of the record as long as they are not accessing the same record.

Is there anyone who has the same thoughts or better ones? For the exam alone, I will choose the synchronization solution, since the instructions didn't say anything about that and it's easier to implement. But as a learner, I'd like to know the sophisticated one, the one without synchronization.

I used multiple data instances for each public client request. My reasoning for this was that it would improve performance by allowing for greater throughput and that it would make the code easier to understand for a junior programmer.

However after submission I did some tests and found that my data version with the local RandomAccessFile instances ran about five times slower that a Version with a single synchronized RAF file. While multiple RAF instances sounds good in theory in reality the overhead involved in opening a new RAF for each client request is actually very high compared to the performance bottleneck of each thread sharing a single RAF instance.

I went with the local RAF instances in the end but plenty of people have passed using both approaches. Once you have stated a good enough reaon for using one approach over the other you will be fine

[Tai Hu]

Good answer Mark! I think I should reconsider my approach. Initially I used single RAF and synchronized on this single RAF for all methods (read, update, delete and find). However, the problem with this is we lock the whole data file and only allow one thread at a time. So now I switched to use ReetrantReadWriteLock and synchronized delete and update methods on write lock and read, find methods on read lock. To do it this way, we could allow multiple read at the same time. But I have to open RAF in each method calls. I will do a performance test to see if there is a big difference between those 2 approach.

[Mingwei Jiang]

Thank you guys for your answers. Mark is right that opening and closing the RAFs will be quite costly. How about maintain a pool for RAFs? We keep some RAFs open in the pool and close some if there're too many.

[Mark Smyth]

Originally posted by Mingwei Jiang:
Thank you guys for your answers. Mark is right that opening and closing the RAFs will be quite costly. How about maintain a pool for RAFs? We keep some RAFs open in the pool and close some if there're too many.

Yeah I think that that would be the ideal solution and is certainly something that you would do with DB connections for example, I just felt that it was a bit of overkill for the project scope.

I would probably be a good learning experience if you wished to write a RAF pool, however I would always be reluctant to add unnescessary complexity into the implementation just in case something goes wrong. But maybe I'm just too conservative

[Mingwei Jiang]

Yeah, I will keep it simple since the instructions said this system is just a learning experience before going on to a web based system and didn't expect much reuse.

A simple solution is preferred.