• 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

Record Data Cache.

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

I am caching the record data in a hashtable and having synchronised blocks where I wait for the lock on this hashtable before creating or updating or deleting, in the corresponding methods.

Here I am synchronizing the method so that no other thread changes the recNo or data or the lockCookie while a thread a executing this method.



I am wondering if this is acceptable (or looks dump??). Any suggestion is appreciated.

Thanks,

Muthaiah.
 
Ranch Hand
Posts: 146
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
It's very different to whay I'm doing, but then there are loads of ways of doing things. I'd suggest that you make very, very sure that there is no possibility of introducing a thread deadlock situation by having a sunchronised block within a synchronised method as you've suggesting.

Do you need to synchronise the method itself? As far as I can see, recNo and lockCookie are thread local variables (each thread has its own stack, so other threads can't change the values of them).
 
Don't get me started about those stupid light bulbs.
reply
    Bookmark Topic Watch Topic
  • New Topic