• 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

Single or multiple instances of Data class

 
Ranch Hand
Posts: 57
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Everyone
I have been reading all the different mails on this site and have found the information incedibly useful however I have a question concerning the fact that there have been many references to there being only one Data instance and it should be passed to the individual Connection Objects created for each client.
In my assignment the data store uses a RandomAccessFile to access the data so if each client is using the same instance of the Data object then at any one time only one operation can be taking place, whether a read or a write, because of the shared FilePointer. The 'seek() then read()' or 'seek() then write()' must be atomic and synchronized to prevent another thread from moving the FilePointer in the middle of the seek() and second method call so there can never be any truly concurrent DB access.
If each client were to receive its own instance of the Data class (the recordCount would be made static and its access synchronized) then there could be concurrent access for each client on the data store as each would have its own FilePointer and multiple clients could be reading the same record at the same time if need be.
If a client wanted to modify the data store then they would have to get a lock on the particular record by storing their ID in a static Collection used by all of the clients so the lock(), read(), modify(), write() unlock() sequence would still be atomic and write operations would be sequential.
Please tell me if my thinking is incorrect as I can't see any way to get away from the problem of the shared FilePointer as can't see that having sequential Data class operations is really concurrent.

Many thanks and kindest regards
Sam
 
Ranch Hand
Posts: 2937
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Sam,
You are on the right track. Some people chose an alternative design where each client gets its own instance of data, but I don't think it's very intuitive or safe.
Eugene.
 
Sam O'Neill
Ranch Hand
Posts: 57
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks for your input Eugene, much appreciated.
Sam
 
author
Posts: 3252
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
My instructions (2.5 yrs or so ago) explicitly stated that I was not to complicate the design for the sake of performance.
- Peter
 
Sam O'Neill
Ranch Hand
Posts: 57
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks Peter
Yes I think I am perceiving more compexity then necssary. Having read so many books on this I am confusing what I have read with what the asssigment actually asks for. Feeling much happier about decision process now.
Sam
 
reply
    Bookmark Topic Watch Topic
  • New Topic