• 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

[URLyBird] Synchronization issues and null terminated fields problems

 
Greenhorn
Posts: 6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi all,

I have started to work my assignment and after a week, I thought I had completed all the classes behind the DB interface. After reading a bit previous threads, I realize my mistakes, but I still have doubts about few things. I would really appreciate if you could help me clear them out.

1- Validity of the synchronization solution
Being new to synchronization, I went for what I thought was the easiest solution : using the synchronized key word as soon as I suspected thread concurrency could threaten the consistency of the data. This means that most of my methods uses it soon after their declaration. I am accessing the file with a RandomAccessFile object, and this is on this object that I am synchronizing on. The result of that is each operation is sequential, a thread trying to delete record 2 will have to wait until the thread modifying record 5 releases the lock on the RandomAccessFile object. I was happy with this, ready to document how slow this would be and possible solution, until I read somewhere that this (having a sequential access) would certainly cause me to fail. I cannot not find the thread anymore but I am pretty sure it was on this forum. Can you please confirm ?

The only alternative to this would be to lock the records individually, meaning that I would have to cache the data (which I did not, thinking that modifying the file directly was more solid/reliable).

2- Field are null terminated
I got confused by a paragraph in the assignment saying that the fields are "null terminated if less than the maximum length for the field". In the DB file provided, spaces are written where we should have seen null. So I took the decision to do the same and pad my fields with spaces as per below. Is this something you would recommand ?
tempField being the current String field, tempByteArray an array of the field expected size, and BLANK_BYTE = ' '

3- Is the value generated by the lock method the one that should be written on the last field of the record ? The assignment specify that this should be an 8 digit number, so I have limited the possible range for the cookie, starting from 10000000 to 99999999.

Thanks in advance. Please let me know if I am breaking any forum rule by posting the code above.

++

Sandrew
 
Sheriff
Posts: 11604
178
Hibernate jQuery Eclipse IDE Spring MySQL Database AngularJS Tomcat Server Chrome Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,

Welcome to the JavaRanch!

1/ you have to make sure your Data class will be thread-safe. And you'll have to implement a locking mechanism for your records. You could make your Data class thread-safe in different ways (marking your methods synchronized, use a synchronized block on some specific object,...). The locking mechanism for your records (purpose excellently described in ScjdFaq) should occur concurrently (like explained here). But it won't be automatic failure when threadB has to wait to lock record 5 (or delete record 6), because threadA is reading record 2. Because if you synchronize all your methods (like I did) only 1 thread can access a method of an instance at the same time (and all other threads will have to wait until this thread is done executing that method).

2/ nothing wrong with using spaces to pad the fields (I did it too).

3/ the customer id is a number (8 digits) that the CSR (user of your client application) has to enter. This has nothing to do with the generated lockCookie.

Kind regards,
Roel
 
Ranch Hand
Posts: 136
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I might be a lil wrong in this but Another approach would be to use strings.
Then you can use String.format method to fit the data in the appropriate space.

It will be padded with whitespace ultimately. But it will be simpler to implement
 
You ought to ventilate your mind and let the cobwebs out of it. Use this cup to catch the tiny ads:
a bit of art, as a gift, the permaculture playing cards
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic