• 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

FBNS: Be threadsafe, but only lock write operations??

 
Ranch Hand
Posts: 37
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi.

I have a question about specifications. It says in pretty strong language
that I should be careful to only lock write operations.. but just below it
is talks about making sure that suncertify.db has to be threadsafe.

I doubt that this is possible. How can I have race conditions telling me
the wrong number of seats on a flight and be threadsafe.

I am puzzled.
 
Ranch Hand
Posts: 357
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Ian,

I am not familiar with the FBNS assignment, but for now I'll assume that it must allow you to book seats on an airplane and you are wondering how to prevent that a seat is booked twice because your read-method said it was available?

The standard solution to that is to combine read and update within a lock/unlock combo. So like this:

- lock seat X
- read seat X and check that it is available
(if it is available now, we can be sure that it remains available, because it is locked).
- update seat X
- unlock seat X

HTH,

Frans.
 
Ian Wark
Ranch Hand
Posts: 37
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Frans,

Actually, I was thinking more along the lines of what was meant by "threadsafe"; but now that I scrutinize it again, it seems that it is probably referring to the situation with updating seats only. I was referring to when the GUI presented information to the client. During searches the number of seats displayed may be incorrect. To me that does not sound "threadsafe", because we still have race conditions happening for read-only operations.
 
Frans Janssen
Ranch Hand
Posts: 357
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Can you elaborate some more about what race conditions you mean?

Do you mean that the number of seats may differ because the reading of a seat could occur just before or just after the seat is booked by another client? Because that I think can never be solved, so it should not be a cause for concern.

Frans.
 
Ian Wark
Ranch Hand
Posts: 37
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Frans,

Thank you for your help. I think I understand the answer to this question now. I meant that since it was possible to read from the database at the
same time it was being written to, that did not seem very "threadsafe". But
I'm pretty sure that the specs are only worried about simultaneous writes to the database.
 
Frans Janssen
Ranch Hand
Posts: 357
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Aha,

In that case you might try to search this forum on "dirty reads". It has been discussed quite recently.

In my assignment I did not bother to forbid dirty reads (reading a locked record), but I did make the access methods synchronized, so that a record could not be read at the same time that it was being written, because then a corrupt record could be read.

Frans.
 
Ian Wark
Ranch Hand
Posts: 37
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Frans,

This is exactly the kind of thing I was concerned about. That is, reading a corrupt record [a record in the middle of being updated]. However, I am trying to use the "one database instance per client" idea that Habibi has pointed out in 126-7 in his co-authored book. That means that I gain nothing by synchronizing on the methods in Data.java, because the locking schema is class-based. I take it that you had a singleton database, instead.

So how can I prevent this?

I read some very lengthy threads on the new NIO that make some guarantees about the writing mechanism being thread-safe, but [if I implemented this] does this mean that I would prevent reading a record that was in the middle of being updated? Pretty fuzzy about this idea.

Is there something else I could do?
 
Frans Janssen
Ranch Hand
Posts: 357
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Ian,

I did not express myself correctly in my last post: I did no make the read and update methods synchronized, but inside these methods I synchronized on a (Singleton) object representing the record. I did have multiple instances of the Data class, so synchronizing on its methods would indeed not help.

I never looked into NIO, so I cannot help you on that,

Frans.
 
Consider Paul's rocket mass heater.
reply
    Bookmark Topic Watch Topic
  • New Topic